Re: Collaboration on standard Wayland protocol extensions

[Benoit Gschwind]

Hello Drew,

After reading the thread stream, I think there is two mixed questions in
your email that is missleading. And most reply try to address both in
one reply. I thing Daniel get the point (if I understood him well).

I read the two following questions:

[1] As almost all compositor will need the following features:
- Screen capture
- Output configuration
- More detailed surface roles (should it be floating, is it a modal,
  does it want to draw its own decorations, etc)
- Input device configuration.

It would be nice if we go around a table to define some shared protocol.
For those interested I will start writing an XML spec. you are welcome
to contribute.

[2] This features are mandatory and should be in the core protocol.


If my reading is correct, I reply to [1]:

I'm in, I would like to avoid implements tools that setup screen layout,
keymaping and screen capture. Thus having a protocol to handle those
case is welcome. From my point of view of WM developer (in opposition of
DE developer)


For [2], I suggest that you starting with not-adopted protocol
specification and if they gather enough approval, you try to push it as
_optionnal_ standard protocol. By optionnal I mean the compositor
developer can choose to implement it or not. by standard I mean if a
developer want implement those feature we strongly encouraged developper
to use them instead of providing a new one.

Best regards.

--
Benoit (blocage) Gschwind

Le 27/03/2016 22:34, Drew DeVault a écrit :
> 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,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration
> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
> 
> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Simon McVittie]

On 29/03/16 13:11, Drew DeVault wrote:
> 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 /proc/cmdline, from which
> we can get the binary path.

This line of thinking is a trap: rummaging in /proc/$pid is not suitable
for use as a security mechanism. If a client can queue up a malicious
privileged action (stuff it into the socket's send-buffer), and then
race with the compositor to exec() something that would legitimately be
allowed to take that action before the request is processed, then you lose.

See  for details of
the equivalent in D-Bus. Mainline dbus on Unix was never vulnerable to
this (because we use credentials-passing to get the uid), but there used
to be an out-of-tree LSM integration patch set (for Maemo) that was.
(That bug was about documenting the attack so that we never accidentally
introduce it.)

If you want to map processes to executable-based privilege domains in a
way that cannot be faked, you will have to use their LSM labels
(SELinux, Smack or other xattr-based labelling, or AppArmor or other
path-based labelling) which are specifically designed to do this. A
Wayland equivalent of D-Bus' GetConnectionCredentials() would probably
be useful.

S
-- 
Simon McVittie
Collabora Ltd. 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Daniel Stone]

Hi,

On 31 March 2016 at 00:16, Drew DeVault  wrote:
> Simply because xrandr was/is a poorly implemented mess doesn't mean that
> we are going to end up making a poorly implemented mess. We have the
> benefit of hindsight. After all, xorg is a poorly implemented mess but
> we still made Wayland, didn't we? (Though some could argue that we've
> just ended up with a well implemented mess...)

X and Wayland protocols have very different design principles guiding
them. X (often by necessity) exposes as much as possible of its
internal workings to clients, and allows total external manipulation.
That's not the case for Wayland, so what you're proposing is a
significant departure.

Cheers,
Daniel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

Simply because xrandr was/is a poorly implemented mess doesn't mean that
we are going to end up making a poorly implemented mess. We have the
benefit of hindsight. After all, xorg is a poorly implemented mess but
we still made Wayland, didn't we? (Though some could argue that we've
just ended up with a well implemented mess...)

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault  wrote:
>> Thirdly, it's important to take a step back. 'Wayland doesn't support
>> middle-button primary selections' is a feature gap compared to X11;
>> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
>> the forest of user-visible behaviour for the trees of creating
>> protocol.
>
> I think you're missing what users are actually using. You'd be surprised
> at how many power users are comfortable working with tools like xrandr
> and scripting their environments.

I've removed myself from the protocol talk so far, but I have to call
this one out. XRandR might be one of the most unfortunate APIs I have
ever dealt with, on both sides of the equation.

* It deals with "outputs" by "index", implying that outputs are static
and ordered. This is not the case in today's equipment with laptop
lids and docks and tons of ports.

* There's *no* way to specify whether something is a temporary display
configuration or should be saved. I plug and unplug external monitors
on my laptop every day, but I don't want a second output to always
behave the same way. Projectors should be in mirror mode. So already
you have multiple configurations, keyed by EDIDs.

* The authors wanted to make hotplug work even when nothing was poking
XRandR, but this just meant that desktops that do store complex
configuration had to wait until XRandR auto-reconfigured before saying
"no, bad computer" and overwriting any configuration it wanted. Two
mode-sets for the price of one.

* The command-line tool made it easy for users to poke the X server
directly, bypassing the DE entirely, leading to cases where the
Settings panel showed bizarre, inconsistent results because the
intended configuration wasn't updated for the manual changes the user
made.

* In some cases, like touchscreens, you *need* input to be mapped to
screen rotation and orientation. Input mapping was half-bolted onto
XInput and XRandR as an after-thought.

* Games which wanted to change the resolution often did it through
XRandR. These rarely worked if users had a complex configuration that
used rotated outputs, etc., or even just had more than one monitor,
leaving users with broken configurations. If the game crashed, users
were stuck with a permanently small screen.

* Similarly to the above, applications which want to react to
resolution changes (e.g. a window manager which wants to resize
windows, or a desktop that wants to reorder desktop icons) is unaware
if such a change is temporary or permanent. The result is that all
your desktop icons got put in a 640x480 box after you launched a game.

* Not to mention that the only event you get out of XRandR is an
all-encompassing "quick! something changed!!" event, which doesn't
even tell if you if it was simply accepting that the configuration you
just made went through successfully, whether it was an auto-configure
from a hotplug, or whether it was some other program poking the API.

* A partial repeat of the above, XRandR was intended for a low-level
"mechanism, not policy" API, but quickly got policy bolted on
after-the-fact because users weren't running tools which actually
supplied the policy. I am very skeptical of users who try to
lego-brick their way through DEs because "it's all bloat, I don't
really need a window manager, I can just skirt along with raw X11"
(because we committed ourselves to making it half-work) and I don't
want to encourage this behavior in Wayland. Let's do it right and
mandate real policy.

(This also doesn't even touch the incredible unfortunate hacks [0] we
have had to do at Endless to support HDMI TVs that need underscan
support, which work by changing the mode-list at runtime based on a
configurable border... which is specified in the mode's XSkew field,
because we didn't have any better place to put it)

We can talk about independent protocols and APIs for each of these use
cases (with no guarantee that Wayland is the IPC mechanism at hand),
but let's not bolt on a "wl_randr" that doesn't even begin to solve
the basic problems at hand because users run xrandr today and we have
to support that use case

[0] 
https://github.com/endlessm/xf86-video-intel/commit/391771f1652477863ece6da90b81dddb3ecb148a

> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 30/03/16 09:33, Jasper St. Pierre wrote:

I really hope that distributions don't see security policies as a
differentiator. This is how we got SELinux vs. AppArmor and real-world
apps having to ship both kinds of policies (or Fedora flat out
ignoring any idea of third-parties and such and including literally
every application ever in its contrib policy file
https://github.com/fedora-selinux/selinux-policy/tree/f23-contrib).


I would also *hate* that. I hate distros that do not ship software as 
vanilla as possible :s


However, what may save us here is that the policy is very high-level and 
it should be quite hard to differentiate!


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

I really hope that distributions don't see security policies as a
differentiator. This is how we got SELinux vs. AppArmor and real-world
apps having to ship both kinds of policies (or Fedora flat out
ignoring any idea of third-parties and such and including literally
every application ever in its contrib policy file
https://github.com/fedora-selinux/selinux-policy/tree/f23-contrib).

On Tue, Mar 29, 2016 at 11:28 PM, Martin Peres  wrote:
> On 30/03/16 01:12, Olav Vitters wrote:
>>
>> On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote:
>>>
>>> We thus wanted to let distros take care of most of the policies (which
>>> does not amount to much and will likely come with the application
>>> anyway). However, some distros or devices come with a system
>>> that already defines security policies and they will likely not want
>>> a proliferation of storage places. Hence why we allowed for
>>> multiple backends. But this is an exception rather than the rule.
>>
>> Why should every distribution decide on some policy? The default way
>> should work sanely and the way that a user would experience it makes
>> sense. I help out with Mageia (+GNOME), I'm 98% sure Mageia has 0
>> interest in creating/developing such a policy.
>
> In WSM, you can set default behaviours for interfaces. This should cover
> your use case.
>
> However, remember this: If it is not the user or the distribution, then you
> are basically trusting the developer of the application... which basically
> means we are back to the security of X11.
>
>> e.g. Linus complaining about (IIRC) needing to provide a root password
>> after plugging in a printer. If we create such a situation again I might
>> even understand why he's rants :-P
>
> This would be utterly ridiculous, and this is what we addressed here:
> http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 30/03/16 01:12, Olav Vitters wrote:

On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote:

We thus wanted to let distros take care of most of the policies (which
does not amount to much and will likely come with the application
anyway). However, some distros or devices come with a system
that already defines security policies and they will likely not want
a proliferation of storage places. Hence why we allowed for
multiple backends. But this is an exception rather than the rule.

Why should every distribution decide on some policy? The default way
should work sanely and the way that a user would experience it makes
sense. I help out with Mageia (+GNOME), I'm 98% sure Mageia has 0
interest in creating/developing such a policy.
In WSM, you can set default behaviours for interfaces. This should cover 
your use case.


However, remember this: If it is not the user or the distribution, then 
you are basically trusting the developer of the application... which 
basically means we are back to the security of X11.



e.g. Linus complaining about (IIRC) needing to provide a root password
after plugging in a printer. If we create such a situation again I might
even understand why he's rants :-P

This would be utterly ridiculous, and this is what we addressed here:
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Graesslin]

On Tuesday, March 29, 2016 8:14:25 AM CEST Drew DeVault wrote:
> 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/?
> > p=kwayland.git=blob=8bc106c7c42a40f71dad9a884824a7a9899e7b2f=818e32
> > 0bd99867ea9c831edfb68c9671ef7dfc47=src
> > %2Fclient%2Fprotocols%2Fserver-decoration.xml
> 
> Excellent. The protocol looks like it'll do just fine.
> 
> > I think especially for compositors like sway that can be very helpful. For
> > Qt we implemented support in our QPT plugin for Plasma. So if sway wants
> > to use it I can give you pointers on how to use it in your own QPT plugin
> > (if you don't have one yet how to create it) and to use it to force
> > QtWayland to not use the client side decorations.
> 
> I would love to see something like that. Can we work on a model that
> would avoid making users install qt to install Sway?

Ah I think there is a small misunderstanding on the QPT plugin. QPT is the Qt 
Platform Theme which is a plugin loaded into Qt applications to adjust it to 
the platform. So to say a standardized way for LD_PRELOAD.

So you would not have to force a toolkit on your users. It's just that when a 
Qt application is used you can provide a plugin to make Qt apps behave better.

> Honestly I'd like
> to just set an environment variable to turn off CSD where possible, for
> both Qt and GTK. I'm still trying to avoid forcing a toolkit on users.

For Qt you can try:
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1

it gets rid of Qt's CSD deco and replaces them by nothing. We have that set in 
our QPT plugin.

And yeah, in general it would be nice to have the toolkits implement this 
protocol. We didn't go for that yet as we had a release schedule mismatch 
between Plasma and Qt.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Graesslin]

On Tuesday, March 29, 2016 8:12:32 AM CEST Drew DeVault wrote:
> 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=818e32
> > 0bd99867ea9c831edfb68c9671ef7dfc47=src
> > %2Fclient%2Fprotocols%2Foutput-management.xml
> > 
> > and
> > 
> > https://quickgit.kde.org/?
> > p=kwayland.git=blob=747fc264b7e6a40a65a0a04464c2c98036a84f0f=818e32
> > 0bd99867ea9c831edfb68c9671ef7dfc47=src
> > %2Fclient%2Fprotocols%2Foutputdevice.xml
> > 
> > It's designed for our specific needs in Plasma. If it's useful for others,
> > we are happy to share and collaborate.
> 
> It looks like something I could use in Sway. I like it. I'm going to see
> how well it integrates with Sway and probably write a command line tool
> to interface with it. I think that it would be useful to put this under
> the permissions system, though, once that's put together.

We already have a command line tool for it :-)

It's kscreen-doctor which you can find in libkscreen. I've cc-ed sebas who 
wrote this tool (and also the protocol).

And yes it's something for the permission system. We clearly do not want 
everybody to be able to change the screen setup.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

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 /proc/cmdline, from which
> we can get the binary path. We can even look at /proc/exe and produce a
> checksum of it, so that programs become untrusted as soon as they
> change.

you can do that... but there are race conditions. a pid can be recycled.
imagine some client just before it exits sends some protocol to request doing
something "restricted". maybe you even check on connect, but let's say this
child exits and you haven't gotten the disconnect on on the fd yet because there
is still data to read in the buffer. you get the pid while the process is
still there, then it happens to exit.. NOW you check /proc/PID ... but in
the mean time the PID was recycled with a new process that is "whitelisted"
so you check this new replacement /proc/PID/exe and find it's ok and ok the
request from the old dying client... BOOM. hole.

it'd be better to use something like smack labels - but this is not used
commonly in linux. you can check the smack label on the connection and auth by
that as smack label then can be in a db of "these guys are ok if they have
smack label "x"" and there is no race here. smack labels are like containers
and also affect all sorts of other access like to files, network etc.

but the generic solution without relying on smack would be to launch yourself -
socketpair + pass fd. :) it has the lowest chance of badness. this works if the
client is a regular native binary (c/c++) or if its a script because the fd
will happily pass on even if its a wrapper shell script that then runs a binary.

> > i know - but for just capturing screencasts, adding watermarks etc. - all
> > you need is to store a stream - the rest can be post-processed.
> 
> Correct, if you record to a file, you can deal with it in post. But
> there are other concerns, like what output format you'd like to use and
> what encoding quality you want to use to consider factors like disk
> space, cpu usage, etc. And there still is the live streaming use-case,
> which we should support and which your solution does not address.

given high enough quality any post process can also transcode to another
format/codec/quality level while adding watermarks etc. a compositor able to
stream out (to a file or whatever) video would of course have options for
basics like quality/bitrate etc. - the codec libraries will want this info
anyway...

> > let's talk about the actual apps surfaces and where they go - not
> > configuration of outputs. :)
> 
> No, I mean, that's what I'm getting at. I don't want to talk about that
> because it doesn't make sense outside of e. On Sway, the user is putting
> their windows (fullscreen or otherwise) on whatever output they want
> themselves. There aren't output roles. Outputs are just outputs and I
> intend to keep it that way.

enlightenment ALSO puts windows "on the current screen" by default and you can
move them to another screen, desktop etc. as you like. hell it has the ability
to remember screen, desktop, geometry, and all sorts of other state and
re-apply it to the same window when it appears again. i use this often myself
to force apps to do what i want when they keep messing up.. i'm not talking
about manually moving things or the ability for a compositor/wm to override and
enforce its will.

i am talking about situations where you want things to "just work" out of the
box as they might be intended to without forcing the user to go manually say
"hey no - i want this". i'm talking about a situation like
powerpoint/impress/whatever where when i give a presentation on ONE screen i
have a smaller version of the slide, i also have the preview of the next slide,
a count-down timer for the slide talk, etc. and on the "presentation screen" i
get the actual full presentation. I should not have to "manually configure
this". impress/ppts/whatever should be able to open up 2 windows and
appropriately tag them for their purposes and the compositor then KNOWS which
screen they should go onto.

impress etc. also need to know that a presentation screen exists so it knows to
open up a special "presentation window" and a "control window" vs just a
presentation window. these windows are of course fullscreen ones - i think we
don't disagree there.

the same might go for games - imagine a nintento DS setup. game has a control
window (on the bottom screen) and a "game window" on the top. similar to
impress presentation vs control windows. imagine a laptop with 2 screens. one
in the normal place and one where your keyboard would be... similar to the DS.
maybe we can talk flight simulators which may want to span 3 monitors
(left/middle/right), due to different screens able to do different refresh
rates etc. you really likely want to have 3 

Re: Collaboration on standard Wayland protocol extensions

[Olav Vitters]

On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote:
> We thus wanted to let distros take care of most of the policies (which
> does not amount to much and will likely come with the application
> anyway). However, some distros or devices come with a system
> that already defines security policies and they will likely not want
> a proliferation of storage places. Hence why we allowed for
> multiple backends. But this is an exception rather than the rule.

Why should every distribution decide on some policy? The default way
should work sanely and the way that a user would experience it makes
sense. I help out with Mageia (+GNOME), I'm 98% sure Mageia has 0
interest in creating/developing such a policy.

e.g. Linus complaining about (IIRC) needing to provide a root password
after plugging in a printer. If we create such a situation again I might
even understand why he's rants :-P

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 27/03/16 23:34, 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,
Kwin, and wayland-devel) to collaborate on some shared protocol
extensions for doing a handful of common tasks such as display
configuration and taking screenshots. Life will be much easier for
projects like ffmpeg and imagemagick if they don't have to implement
compositor-specific code for capturing the screen!

I want to start by establishing the requirements for these protocols.
Broadly speaking, I am looking to create protocols for the following
use-cases:

- Screen capture
- Output configuration
- More detailed surface roles (should it be floating, is it a modal,
   does it want to draw its own decorations, etc)
- Input device configuration

I think that these are the core protocols necessary for
cross-compositor compatability and to support most existing tools for
X11 like ffmpeg. Considering the security goals of Wayland, it will also
likely be necessary to implement some kind of protocol for requesting
and granting sensitive permissions to clients.

How does this list look? What sorts of concerns do you guys have with
respect to what features each protocol needs to support? Have I missed
any major protocols that we'll have to work on? Once we have a good list
of requirements I'll start writing some XML.

--
Drew DeVault


We had discussions about it years ago and here are the results of them:
http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/

And here is the software we created, under the name "Wayland Security 
Modules":

http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf
https://github.com/mupuf/libwsm

This approach has generally be liked by KDE, but not by Gnome who, last 
i heard, did not care about cross-platform apps doing privileged 
operations. This may have changed since they also decided to work on 
sandboxing (xdg-app) and implemented something like the following 
approach when they said they would never do because it changed the API:

http://mupuf.org/blog/2014/05/14/introducing-sandbox-utils-0-6-1/

I really wish we can have everyone onboard on one solution to get these 
cross-platform apps and so far, I do not see any better solution than WSM.


Martin
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

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 require to fork the process directly from compositor and provide
> > a socketpair fd to this process and THAT fd could have extra capabilities
> > attached to the wl protocol. i would do nothing else because as a
> > compositor i cannot be sure what i am executing. i'd hand over the choice
> > of being able to execute this tool to the user to say ok to and not just
> > blindly execute anything i like.
> 
> 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 protocol exists) unless it is executed by the compositor. the compositor
can do whatever it deems "necessary" to ensure it executes only what is
allowed. eg - a whitelist of binary paths. i see this as a lesser chance of a
hole.

> you elaborate on how this changes things? I should also mention that I
> don't really see the sort of security goals Wayland has in mind as
> attainable until we start doing things like containerizing applications,
> in which case we can elimitate entire classes of problems from this
> design.

certain os's do this already - tizen does. we use smack labels. this is why i
care so much about application isolation and not having anything exposed to an
app that it doesn't absolutely need. :) so i am coming from the point of view
of "containering is solved - we need to not break that in wayland" :)

> > all a compositor has to do is be able to capture a video stream to a file.
> > you can ADD watermarking, sepia, and other effects later on in a video
> > editor. next you'll tell me gimp is incapable of editing image files so we
> > need programmatic access to a digital cameras ccd to implement
> > effects/watermarking etc. on photos...
> 
> I'll remind you again that none of this supports the live streaming
> use-case.

i know - but for just capturing screencasts, adding watermarks etc. - all you
need is to store a stream - the rest can be post-processed.

> > > currently possible with ffmpeg. How about instead we make a simple
> > > wayland protocol extension that we can integrate with ffmpeg and OBS and
> > > imagemagick and so on in a single C file.
> > 
> > i'm repeating myself. there are bigger fish to fry.
> 
> I'm repeating myself. Fry whatever fish you want and backlog this fish.
> 
> > eh? ummm that is what happens - unless you close the lid, then internal
> > display is "disconnected".
> 
> I'm snipping out a lot of the output configuration related stuff from
> this response. I'm not going to argue very hard for a common output
> configuration protocol. I've been trying to change gears on the output
> discussion towards a discussion around whether or not the
> fullscreen-shell protocol supports our needs and whether or how it needs
> to be updated wrt permissions. I'm going to continue to omit large parts
> of your response that I think are related to the resistance to output
> configuration, let me know if there's something important I'm dropping
> by doing so.

why do we need the fullscreen shell? that was intended for environments where
apps are only ever fullscreen from memory. xdg shell has the ability for a
window to go fullscreen (or back to normal) this should do just fine. :) sure -
let's talk about this stuff - fullscreening etc.

> > a protocol with undefined metadata is not a good protocol. it's now goes
> > blobs of data that are opaque except to specific implementations., this
> > will mean that other implementations eventually will do things like strip
> > it out or damage it as they don't know what it is nor do they care.
> 
> It doesn't have to be undefined metadata. It can just be extensions. A
> protocol with extensions built in is a good protocol whose designers had
> foresight, kind of like the Wayland protocol we're all already making
> extensions for.

yeah - but you are creating objects (screens) with no extended data - or
modifying them. you don't have or lose the data. :) let's talk about the actual
apps surfaces and where they go - not configuration of outputs. :)

> > but it isn't the user - it's some game you download that you cannot alter
> > the code or behaviour of that then messes everything up because its creator
> > only ever had a single monitor and didn't account for those with 2 or 3.
> 
> But it _is_ the user. Let the user configure what they want, however
> they want, and make it so that they can both do this AND deny crappy
> games the right to do it as well. This applies to the entire discussion
> broadly, not necessarily just to the output configuration bits (which I
> retract).
> 
> > because things like 

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

On Mon, 28 Mar 2016 10:55:05 -0400 Drew DeVault  said:

> On 2016-03-28 11:03 PM, Carsten Haitzler wrote:
> > should we? is it right to create yet another rsecurity model in userspace
> > "quickly" just to solve things that dont NEED solving at least at this
> > point.
> 
> I don't think that the protocol proposed in other branches of this
> thread is complex or short sighted. Can you hop on that branch and
> provide feedback?

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 require to fork the process directly from compositor and provide a
socketpair fd to this process and THAT fd could have extra capabilities
attached to the wl protocol. i would do nothing else because as a compositor i
cannot be sure what i am executing. i'd hand over the choice of being able to
execute this tool to the user to say ok to and not just blindly execute
anything i like.

> > adding watermarks can be done after encoding as another pass (encode in high
> > quality). hell watermarks can just be a WINDOW (surface) on the screen. you
> > don't need options. ass for audio - not too hard to do along with it. just
> > offer to record an input device - and choose (input can be current mixed
> > output or a mic ... or both).
> 
> You're still not grasping the scope of this. I want you to run this
> command right now:
> 
> man ffmpeg-all
> 
> Just read it for a while. You're delusional if you think you can
> feasibly implement all of these features in the compositor. Do you

all a compositor has to do is be able to capture a video stream to a file. you
can ADD watermarking, sepia, and other effects later on in a video editor. next
you'll tell me gimp is incapable of editing image files so we need programmatic
access to a digital cameras ccd to implement effects/watermarking etc. on
photos...

> honestly want your screen capture tool to be able to add a watermark?

no - this can be done in a video editing tool later on. just record video at
high quality so degradation is not an issue.

> How about live streaming, some people add a sort of extra UI to read off
> donations and such. The scope of your screen capture tool is increasing
> at an alarming rate if you intend to support all of the features

no. i actually did not increase the scope. i kept it simple to "compositor can
write a file". everything else can be done in a post-processing task. that file
may include captured audio at the same time from a specific audio input.

> currently possible with ffmpeg. How about instead we make a simple
> wayland protocol extension that we can integrate with ffmpeg and OBS and
> imagemagick and so on in a single C file.

i'm repeating myself. there are bigger fish to fry.

> > exactly what you describe is how e works out of the box. no sscripts needed.
> > requiring people write script to do their screen configuration is just
> > wrong. taking the position of "well i give up and won't bother and will
> > just make my users write scripts instead" iss sticking your head in the
> > sand and not solving the problem. you are now asking everyone ELSE who
> > writes a compositor to implement a protocol because YOU wont solve a
> > problem that others have solved in a user friendly manner.
> 
> What if I want my laptop display to remain usable? Right now I'm docked

eh? ummm that is what happens - unless you close the lid, then internal display
is "disconnected".

> somewhere else and I actually do have this scenario - my laptop is one
> of my working displays. How would I configure the difference between
> these situations in your tool? What if I'm on a laptop with poorly
> supported hardware (I've seen this before) where there's a limit on how
> many outputs I can use at once? What if I want to write a script where I
> put on a movie and it disables every output but my TV automatically? The
> user is losing a lot of power here and there's no way you can satisfy
> everyone's needs unless you make it programmable.

not true. this can be encapsulated without it being programmable. i have yet to
find a laptop that cannot run all its outputs, but the general limitation can
be accounted for - eg via prioritization. if you have 4 outputs and only 3 can
work at a time - then chose the 3 with the highest priority - adjust priority
of screens to have what you want.

> > > Base your desktop's tools on the common protocol, of course. Gnome
> > > settings, KDE settings, arandr, xrandr, nvidia-settings, and so on, all
> > > seem to work fine configuring your outputs with the same protocol today.
> > > Yes, the protocol is meh and the implementation is a mess, but the
> > > clients of that protocol aren't bad by any stretch of the imagination.
> > 
> > no tools. why do it? it's built in. in order for screen config "magic" to
> > work  set of metadata  attached to screens. you can set priority (screens
> > get numbers from highest to 

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

On Sun, 27 Mar 2016 16:34:37 -0400 Drew DeVault  said:

> 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,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture

i can tell you that screen capture is a security sensitive thing and likely
won't get a regular wayland protocol. it definitely won't from e. if you can
capture screen, you can screenscrape. some untrusted game you downloaded for
free can start watching your internet banking and see how much money you have
in which accounts where...

the simple solution is to build it into the wm/desktop itself as an explicit
user action (keypress, menu option etc.) and now it can't be exploited as it's
not pro grammatically available. :)

i would imagine the desktops themselves would in the end provide video capture
like they would stills.

of course you have the more nasty variety of screencapture which is "screen
sharing" where you don't want to just store to a file but broadcast live. and
this then even gets worse - you would want to be able to inject events -
control the mouse, keyboard etc. from an app. this is a nasty slippery slope at
least i don't want to walk down any time soon. this is a bit of a pandoras box
of security holes to open up.

> - Output configuration

why? currently pretty much every desktop provides its OWN output configuration
tool that is part of the desktop environment. why do you want to re-invent
randr here allowing any client to mess with screen config. after YEARS of games
using xvidtune and what not to mess up screen setups this would be a horrible
idea. if you want to make a presentation tool that uses 1 screen for output and
another for "controls" then that's a matter of providing info that multiple
displays exist and what type they may be (internal, external) and clients can
tag surfaces with "intents" eg - this iss a control surface, this is an
output/display surface. compositor will then assign them appropriately.

same for games. same for media usage. etc. - there is little to no need for
clients to go messing with screen setup. this is a desktop/compositor task that
will be handled by that DE as it sees fit (some may implement a wl protocol but
only on a specific FD - maybe a socketpair to a forked child) or something dbus
or some private protocol or maybe even build it directly in to the compositor.
the same technique can be used to allow extended protocol for specific clients
too (socketpair etc.) but just don't expose at all what is not needed.

> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)

that seems sensible and over time i can imagine this will expand.

> - Input device configuration

as above. i see no reason clients should be doing this. surface
intents/roles/whatever can deal with this. compositor may alter how an input
device works for that surface based on this.

> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.

as above. anything apps have no business messing with i have no interest in
having any protocol for. input device config, screen setup config etc. etc. for
sure. screen capture is a nasty one and for now - no. no access. for the common
case the DE can do it. for screen sharing kind of things... you also need input
control (take over mouse and be able to control from app - or create a 2nd
mouse pointer and control that... keyboard - same, etc. etc. etc.). this is a
nasty little thing and in implementing something like this you are also forcing
compositors to work ion specific ways - eg screen capture will likely FORCE the
compositor to merge it all into a single ARGB buffer for you rather than just
assign it to hw layers. or perhaps it would require just exposing all the
layers, their config and have the client "deal with it" ? but that means the
compositor 

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

On Sun, 27 Mar 2016 22:29:57 -0400 Drew DeVault  said:

> On 2016-03-28  8:55 AM, Carsten Haitzler wrote:
> > i can tell you that screen capture is a security sensitive thing and likely
> > won't get a regular wayland protocol. it definitely won't from e. if you can
> > capture screen, you can screenscrape. some untrusted game you downloaded for
> > free can start watching your internet banking and see how much money you
> > have in which accounts where...
> 
> Right, but there are legitimate use cases for this feature as well. It's
> also true that if you have access to /dev/sda you can read all of the
> user's files, but we still have tools like mkfs. We just put them behind
> some extra security, i.e. you have to be root to use mkfs.

yes but you need permission and that is handled at kernel level on a specific
file. not so here. compositor runs as a specific user and so you cant do that.
you'd have to do in-compositor security client-by-client.

> > the simple solution is to build it into the wm/desktop itself as an explicit
> > user action (keypress, menu option etc.) and now it can't be exploited as
> > it's not pro grammatically available. :)
> >
> > i would imagine the desktops themselves would in the end provide video
> > capture like they would stills.
> 
> I'd argue that this solution is far from simple. Instead, it moves *all*
> of the responsibilities of your entire desktop into one place, and one
> codebase. And consider the staggering amount of work that went into
> making ffmpeg, which has well over 4x the git commits as enlightenment.

you wouldn't recreate ffmpeg. ffmpec produce libraries like avcodec. like a
reasonable developer we'd just use their libraries to do the encoding - we'd
capture frames and then hand off to avcodec (ffmpeg) library routines to do the
rest. ffmpeg doesnt need to know how to capture - just to do what 99% of its
code is devoted to doing - encode/decode. :) that's rather simple. already we
have decoding wrapped - we sit on top of either gstreamer, vlc or xine as the
codec engine and just glue in output and control api's and events. encoding is
just the same but in reverse. :) the encapsulation is simple.

> > > - Output configuration
> > 
> > why? currently pretty much every desktop provides its OWN output
> > configuration tool that is part of the desktop environment. why do you want
> > to re-invent randr here allowing any client to mess with screen config.
> > after YEARS of games using xvidtune and what not to mess up screen setups
> > this would be a horrible idea. if you want to make a presentation tool that
> > uses 1 screen for output and another for "controls" then that's a matter of
> > providing info that multiple displays exist and what type they may be
> > (internal, external) and clients can tag surfaces with "intents" eg - this
> > iss a control surface, this is an output/display surface. compositor will
> > then assign them appropriately.
> 
> There's more than desktop environments alone out there. Not everyone
> wants to go entirely GTK or Qt or EFL. I bet everyone on this ML has
> software on their computer that uses something other than the toolkit of
> their choice. Some people like piecing their system together and keeping
> things lightweight, and choosing the best tool for the job. Some people
> might want to use the KDE screengrab tool on e, or perhaps some other
> tool that's more focused on doing just that job and doing it well. Or
> perhaps there's existing tools like ImageMagick that are already written
> into scripts and provide a TON of options to the user, which could be
> much more easily patched with support for some standard screengrab
> protocol than to implement all of its features in 5 different desktops.

the expectation is there won't be generic tools but desktop specific ones. the
CURRENT ecosystem of tools exist because that is the way x was designed to
work. thus the srate of software matches its design. wayland is different. thus
tools and ecosystem will adapt.

as for output config - why would the desktops that already have their own tools
then want to support OTHER tools too? their tools integrate with their settings
panels and look and feel right and support THEIR policies.

let me give you an example:

http://devs.enlightenment.org/~raster/ssetup.png

bottom-right - i can assign special scale factors and different toolkit
profiles per screen. eg one screen can be a desktop, one a media center style,
one a mobile "touch centric ui" etc. etc. - this is part of the screen setup
tool. a generic tool will miss features that make the desktop nice and
functional for its purposes. do you want to go create some kind of uber
protocol that every de has to support with every other de's feature set in it
and limit de's to modifying the protocol because they now have to go through a
shared protocol in libwayland that they cant just add features to as they
please? ok - so these features will be added adhoc in extra 

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

On Mon, 28 Mar 2016 09:00:34 -0400 Drew DeVault  said:

> On 2016-03-28  2:13 PM, Carsten Haitzler wrote:
> > yes but you need permission and that is handled at kernel level on a
> > specific file. not so here. compositor runs as a specific user and so you
> > cant do that. you'd have to do in-compositor security client-by-client.
> 
> It is different, but we should still find a way to do it. After all,
> we're going to be in a similar situation eventually where we're running
> sandboxed applications and the compositor is granting rights from the
> same level of privledge as the kernel provides to root users (in this
> case, the role is almost of a hypervisor and a guest).

should we? is it right to create yet another rsecurity model in userspace
"quickly" just to solve things that dont NEED solving at least at this point.

> > you wouldn't recreate ffmpeg. ffmpec produce libraries like avcodec. like a
> > reasonable developer we'd just use their libraries to do the encoding - we'd
> > capture frames and then hand off to avcodec (ffmpeg) library routines to do
> > the rest. ffmpeg doesnt need to know how to capture - just to do what 99%
> > of its code is devoted to doing - encode/decode. :) that's rather simple.
> > already we have decoding wrapped - we sit on top of either gstreamer, vlc
> > or xine as the codec engine and just glue in output and control api's and
> > events. encoding is just the same but in reverse. :) the encapsulation is
> > simple.
> 
> True, that most of the work is in the avcodec. However, there's more to
> it than that. The entire command line interface of ffmpeg would be
> nearly impossible to build into the compositor effectively. With ffmpeg
> I can capture x, flip it, paint it sepia, add a logo to the corner, and
> mux it with my microphone and a capture of the speakers (thanks,
> pulseaudio) and add a subtitle track while I'm at it. Read the ffmpeg
> man pages. ffmpeg-all(1) is 23,191 lines long on my terminal (that's
> just the command line interface, not avcodec). There's no way in hell
> all of the compositors/DEs are going to be able to fulfill all of its
> use cases, nor do I think we should be trying to.
> 
> Look at things like OBS. It lets you specify detailed encoding options
> and composites a scene from multiple video sources and audio sources,
> as well as letting the user switch between different scenes with
> configurable transitions. It even lets you embed a web browser into the
> final result! All of this with a nice GUI to top it off. Again, we can't
> possibly hope to effectively implement all of this in the compositor/DE,
> or the features of the other software that we haven't even thought of.

adding watermarks can be done after encoding as another pass (encode in high
quality). hell watermarks can just be a WINDOW (surface) on the screen. you
don't need options. ass for audio - not too hard to do along with it. just
offer to record an input device - and choose (input can be current mixed output
or a mic ... or both).

> > the expectation is there won't be generic tools but desktop specific ones.
> > the CURRENT ecosystem of tools exist because that is the way x was designed
> > to work. thus the srate of software matches its design. wayland is
> > different. thus tools and ecosystem will adapt.
> 
> That expectation is misguided. I like being able to write a script to
> configure my desktop layout between several presets. Here's an example -
> a while ago, I used a laptop at work that could be plugged into a
> docking station. I would close the lid and use external displays at my
> desk. I wanted to automatically change the screen layout when I came and
> went, so I wrote a script that used xrandr to do it. It detected when
> there were new outputs plugged in, then disabled the laptop screen and
> enabled+configured the two new screens in the correct position and
> resolution. This was easy for me to configure to behave the way I wanted
> because the tooling was flexible and cross-desktop. Sure, we could make
> each compositor support it, but each one is going to do it differently
> and in their own subtly buggy ways and with their own subset of the
> total possible features and use-cases, and none of them are going to
> address every possible scenario.

exactly what you describe is how e works out of the box. no sscripts needed.
requiring people write script to do their screen configuration is just wrong.
taking the position of "well i give up and won't bother and will just make my
users write scripts instead" iss sticking your head in the sand and not solving
the problem. you are now asking everyone ELSE who writes a compositor to
implement a protocol because YOU wont solve a problem that others have solved
in a user friendly manner.

i've been doing x11 wm's since 1996. i've seen the bad, the ugly and the
horrible. there is no way i want any kind of protocol for configuring the
screen. not after having seen just how much it is abused 

Re: Collaboration on standard Wayland protocol extensions

[Giulio Camuffo]

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), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
>
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
>
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration
>
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.

On this, see 
https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html
I have not been able to continue on that, but if you want to feel free
to grab that proposal.


Cheers,
Giulio

>
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
>
> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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 Giulio's proposal makes sense because it could be used to
> >> both grant and revoke rights on the fly.  
> >
> > I think both solutions have similar merit and I don't feel strongly
> > about either one.  
> 
> 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 gives the compositor that.

More precisely, you cannot gracefully fail to use an interface exposed
via wl_registry. It either works, or the client gets disconnected.
Protocol error always means disconnection, and wl_registry has no other
choice to communicate a "no, you can't use this".

Checking "whether an interface works or not" is also not trivial. It
would likely lead to adding a "yes, this works" event to all such
interfaces, since anything less explicit is harder than necessary. But
why do that separately in every interface rather than in a common
interface?

Btw. I did say in the past that I didn't quite understand or like
Giulio's proposal, but I have come around since. For the above reasons,
it does make sense on a high level.


Thanks,
pq


pgpPowWxixFjE.pgp
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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 this. In general, my opinion is that it is
> > > completely pointless to add Wayland protocols for things that has
> > > nothing to do with Wayland what so ever; we have other display protocol
> > > agnostic methods for that that fits much better.  
> > 
> > I think these features have a lot to do with Wayland, and I still
> > maintain that protocol extensions make sense as a way of doing it. I
> > don't want to commit my users to dbus or something similar and I'd
> > prefer if I didn't have to make something unique to sway. It's probably
> > going to be protocol extensions for some of this stuff and I think it'd
> > be very useful for the same flexibility to be offered by other
> > compositors.
> >   
> > > As a rule of thumb, whether a feature needs a Wayland protocol or not,
> > > one can consider whether a client needs to reference a client side
> > > object (such as a surface) on the server. If it needs it, we should add
> > > a Wayland protocol; otherwise not. Another way of seeing it would be
> > > "could this be shared between Wayland/X11/Mir/... then don't do it in
> > > any of those".  
> > 
> > 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 responsible for making them
> > available.  
> 
> I didn't say the display server shouldn't be the one exposing such an
> API, I just think it is a bad idea to duplicate every display server
> agnostic API for every possible display server protocol.
> 
> >   
> > > > - Screen capture  
> > > Why would this ever be a Wayland protocol? If a client needs to capture
> > > its own content it doesn't need to ask the compositor; otherwise it's
> > > the job of the compositor. If there needs to be a complex pipeline setup
> > > that adds sub titles, muxing, sound effects and what not, we should make
> > > use of existing projects that intend to create inter-process video
> > > pipelines (pinos[0] for example).
> > > 
> > > FWIW, I believe remote desktop/screen sharing support partly falls under
> > > this category as well, with the exception that it may need input event
> > > injection as well (which of course shouldn't be a Wayland protocol).
> > > 
> > > As a side note, for GNOME, I have been working on a org.gnome prefixed
> > > D-Bus protocol for remote desktop that enables the actual remote desktop
> > > things to be implemented in a separate process by providing pinos
> > > streams, and I believe that at some point it would be good to have a
> > > org.freedesktop.* (or equivalent) protocol doing that in a more desktop
> > > agnostic way. Such a protocol could just as well be read-only, and
> > > passed to something like ffmpeg (maybe can even pipe it from gst-launch
> > > directly to ffmpeg if you so wish) in order to do screen recording.  
> > 
> > I know that Gnome folks really love their DBus, but I don't think that
> > it makes sense to use it for this. Not all of the DEs/WMs use dbus and
> > it would be great if the tools didn't have to know how to talk to it,
> > but instead had some common way of getting pixels from the compositor.  
> 
> So if you have a compositor or a client that wants to support three
> display server architectures, it needs to implement all those three
> API's separately? Why can't we provide an API ffmpeg etc can use no
> matter if the display server happens to be the X server, sway or
> Unity-on-Mir?
> 
> I don't see the point of not just using D-Bus just because you aren't
> using it yet. It's already there, installed on your system, it's already
> used by various other parts of the stack, and it will require a lot less
> effort by clients and servers if they they want to support more than
> just Wayland.
> 
> > 
> > I haven't heard of Pinos before, but brief searches online make it look
> > pretty useful for this purpose. I think it can be involved here.
> >   
> 
> Pinos communicates via D-Bus, but pixels/frames are of course never
> passed directly, but via shared memory handles. What a screen
> cast/remote desktop API would do is more or less to start/stop a pinos
> stream and optionally inject events, and let the client know what stream
> it should use.
> 
> >   
> > > I don't think we should start writing Wayland protocols for things that
> > > has nothing to do with Wayland, only because the program where it is
> > > going to be implemented in may already may be doing Wayland things.
> > > There simply is no reason for it.
> > > 
> > > We should simply use the IPC system that we already have that we already
> > > use for things like this (for example color management, inter-process

Re: Collaboration on standard Wayland protocol extensions

[Martin Graesslin]

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,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - 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/?
p=kwayland.git=blob=8bc106c7c42a40f71dad9a884824a7a9899e7b2f=818e320bd99867ea9c831edfb68c9671ef7dfc47=src
%2Fclient%2Fprotocols%2Fserver-decoration.xml

We would be very happy to share this one. It's already in use in Plasma 5.6 
and so far we are quite satisfied with it. It's designed with convergence in 
mind so that it's possible to easily switch the modes (e.g. decorated on 
Desktop, not decorated on phone, no decorations for maximized windows, etc.).

I think especially for compositors like sway that can be very helpful. For Qt 
we implemented support in our QPT plugin for Plasma. So if sway wants to use 
it I can give you pointers on how to use it in your own QPT plugin (if you 
don't have one yet how to create it) and to use it to force QtWayland to not 
use the client side decorations.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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 on this and I
> don't want it to devolve into a flamewar - I'm just not imposing either
> side of the dbus/systemd argument on my users.

If you don't use what others use, then you use something different.

As you don't want to use what other people use, it goes the same way
for other people to not want to use what you use. Whatever the reasons
for either party.

Wayland upstream/community/whatever cannot force neither you nor them
to do against their will.

So your only hope is to compete with technical excellence and
popularity.

> > Pinos communicates via D-Bus, but pixels/frames are of course never
> > passed directly, but via shared memory handles. What a screen
> > cast/remote desktop API would do is more or less to start/stop a pinos
> > stream and optionally inject events, and let the client know what stream
> > it should use.  
> 
> Hmm. Again going back to "I don't want to make the dbus decision for my
> users", I would prefer to find a solution that's less dependent on it,
> though I imagine taking inspiration from Pinos is quite reasonable.

Up to you, indeed, on what you force down your users' throats, but the
fact is, you will always force something on them. Your users don't have
the freedom of choice to use your compositor without Wayland either.
You chose Wayland, your users chose your software.

> > Sorry, I don't see how you make the connection between "Wayland" and
> > "screen capture" other than that it may be implemented in the same
> > process. Wayland is meant to be used by clients to be able to pass
> > content to  and receive input from the display server. It's is not
> > intended to be a catch-all IPC replacing D-Bus.  
> 
> DBus is not related to Wayland. DBus is not _attached_ to Wayland. DBus
> and Wayland are seperate, unrelated protocols and solving Wayland
> problems with DBus is silly.

Correct. Use each to its best effect, not all problems are nails.

If there already is a DBus based solution that just works, why would
someone write a new solution to replace that? There has to be a benefit
for replacing the old for the people using the old solution. It could
be a benefit for the end users of the old, or for the developers of the
old, but if the only benefit is for "outsiders", it gives no motivation.


Thanks,
pq


pgp9Y_tkLaeTx.pgp
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Pekka Paalanen]

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
> > simply require to fork the process directly from compositor and provide a
> > socketpair fd to this process and THAT fd could have extra capabilities
> > attached to the wl protocol. i would do nothing else because as a 
> > compositor i
> > cannot be sure what i am executing. i'd hand over the choice of being able 
> > to
> > execute this tool to the user to say ok to and not just blindly execute
> > anything i like.  
> 
> 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
> you elaborate on how this changes things? I should also mention that I
> don't really see the sort of security goals Wayland has in mind as
> attainable until we start doing things like containerizing applications,
> in which case we can elimitate entire classes of problems from this
> design.

> I'm snipping out a lot of the output configuration related stuff from
> this response. I'm not going to argue very hard for a common output
> configuration protocol. I've been trying to change gears on the output
> discussion towards a discussion around whether or not the
> fullscreen-shell protocol supports our needs and whether or how it needs
> to be updated wrt permissions.

I sense there is a misunderstanding here, that I want to correct.

The fullscreen-shell protocol is completely irrelevant here. It has
been designed to be mutually exclusive to a desktop protocol suite.

The original goal for the fullscreen-shell is to be able to use a
ready-made compositor, e.g. Weston in particular, as a hardware
abstraction layer for a single application. We of course have some demo
programs to use it so we can test it.

That single application would often be a DE compositor, perhaps a small
project which does not want to deal with all the KMS and other APIs but
concentrate on making a good DE at the expense of the slight overhead
that using a middle-man compositor brings.

Now that we have decided that libweston is a good idea, I would assume
this use case may disappear eventually.

There are also no permission issues wrt. to the fullscreen shell
protocol. The compositor exposing the fullscreen shell interface expects
only a single client ever, or works a bit like the VTs in that only a
single client can be active at a time. Ordinarily you set up the
application such, that the parent compositor is launched as part of the
app launch, and nothing else can even connect to the parent compositor.

Fullscreening windows on a desktop has absolutely nothing to do with
the fullscreen shell. Fullscreen shell is not available on compositors
configured for desktop. This is how it was designed and meant to be.


Thanks,
pq


pgp7yYTxqufIB.pgp
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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), and I have
> > reached out to each of the projects this message is addressed to (GNOME,
> > Kwin, and wayland-devel) to collaborate on some shared protocol
> > extensions for doing a handful of common tasks such as display
> > configuration and taking screenshots. Life will be much easier for
> > projects like ffmpeg and imagemagick if they don't have to implement
> > compositor-specific code for capturing the screen!
> >
> > I want to start by establishing the requirements for these protocols.
> > Broadly speaking, I am looking to create protocols for the following
> > use-cases:
> >
> > - Screen capture
> > - Output configuration
> > - More detailed surface roles (should it be floating, is it a modal,
> >   does it want to draw its own decorations, etc)
> > - Input device configuration
> >
> > I think that these are the core protocols necessary for
> > cross-compositor compatability and to support most existing tools for
> > X11 like ffmpeg. Considering the security goals of Wayland, it will also
> > likely be necessary to implement some kind of protocol for requesting
> > and granting sensitive permissions to clients.  
> 
> On this, see 
> https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html
> I have not been able to continue on that, but if you want to feel free
> to grab that proposal.

Hi,

I may have had negative opinions related to some things on Giulio's
proposal, but I have changed my mind since then. I'd be happy to see it
developed further, understanding that it does not aim to solve the
question of authentication but only communicating the authorization,
for now.


Thanks,
pq


pgpbSPEEjJscR.pgp
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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?
> > 
> > there is no way a process can access the socket with privs (even know the
> > extra protocol exists) unless it is executed by the compositor. the 
> > compositor
> > can do whatever it deems "necessary" to ensure it executes only 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 /proc/cmdline, from which
> we can get the binary path. We can even look at /proc/exe and produce a
> checksum of it, so that programs become untrusted as soon as they
> change.

That means you have to recognize all interpreters, or you suddenly just
authorized all applications running with /usr/bin/python or such.

The PID -> /proc -> executable thing works only for a limited set of things.

However, forking in the compositor is secure against that. Assuming the
compositor knows what it wants to run, it creates a connection *before*
launching the app, and the app just inherits an already authorized
connection.

The general solution is likely with containers, as you said. That thing
I agree with.


Thanks,
pq


pgph82G99daC5.pgp
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Giulio Camuffo]

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 Giulio's proposal makes sense because it could be used to
>> both grant and revoke rights on the fly.
>
> I think both solutions have similar merit and I don't feel strongly
> about either one.

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 gives the compositor that.

>
>> >No, the compositor can remember your choice.
>>
>> So, you would be asking users to click on "I agree" and "remember my choice"
>> every time they set up a computer then :D Not nearly as bad, but still bad.
>
> Well, I imagine we'd store their choices in a file somewhere. They can
> bring that file along for the ride.
>
> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 28/03/16 23:47, Drew DeVault wrote:

On 2016-03-28 10:50 PM, Martin Peres wrote:

Client->Server: What features do you support?
Server->Client: These privledged features are available.
Client->Server: I want this feature (nonblocking)
[compositor prompts user to agree]
Server->Client: Yes/no
[compositor enables the use of those protocols for this client]

That looks like the bind operation to me. Why do you need a
new protocol?

How do you propose clients would communicate their intentions to
compositors? I may be misunderstanding.


I was proposing for applications to just bind the interface and see if 
it works or not. But Giulio's proposal makes sense because it could be 
used to both grant and revoke rights on the fly.



So, you are OK with being asked *every time* if you accept that VLC
is trying to go fullscreen? I most definitely am not :D

No, the compositor can remember your choice.


So, you would be asking users to click on "I agree" and "remember my 
choice" every time they set up a computer then :D Not nearly as bad, but 
still bad.



(following what chrome and firefox are doing is likely a good idea).

I agree, permission management on Firefox is good.


Right, we should really aim for something similar, UX-wise.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 28/03/16 16:04, Drew DeVault wrote:

On 2016-03-28  9:08 AM, Giulio Camuffo wrote:

On this, see 
https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html
I have not been able to continue on that, but if you want to feel free
to grab that proposal.

I looked through this protocol and it seems like it's a good start. We
should base our work on this.


Being able to send accept/deny messages to the clients asynchronously 
really will be needed for making good UIs.


We need to be able to revoke rights and add them on the fly.

Martin
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 28/03/16 02:41, Jasper St. Pierre wrote:

You're probably referring to my response when you say "GNOME does not
care about cross-platform apps doing privileged operations". My
response wasn't meant to be speaking on behalf of GNOME. These are my
opinions and mine alone.


I must have mis-remembered then. Sorry.


My opinion is still as follows: having seen how SELinux and PAM work
out in practice, I'm skeptical of any "Security Module" which
implements policy. The "module" part of it rarely happens, since
people simply gravitate towards a standard policy. What's interesting
to me isn't a piece of code that allows or rejects operations, it's
the resulting UI *around* those operations and managing them, since
that's really, at the end of the day, all the user cares about.


The UI is definitely the most important part of this work. I think
we gave already many ideas for the UI part in [1].

As much as possible, we want to avoid having the traditional
ACL-style because not only is it not easy to discover and tweak
but it is also going in the way of users. Instead, we would like
to be as unintrusive as possible.

We thus wanted to let distros take care of most of the policies (which
does not amount to much and will likely come with the application
anyway). However, some distros or devices come with a system
that already defines security policies and they will likely not want
a proliferation of storage places. Hence why we allowed for
multiple backends. But this is an exception rather than the rule.

What we envisioned was that when an app is using a privileged
interface, there would be a new icon in the notification area telling
which app is using what priviledged interface.

Also, when right clicking on a running window, there would be a
"capabilities" entry which, when clicked, would show on top of the
application what are the current capabilities allowed and what is
not. There, the user would be able to change the policy and have
multiple options for each capability:
- Default: (soft/hard allow/deny)
- One time granting (until the app is closed)
- One time revoke (revoke the rights immediatly)


It would be a significant failure to me if we didn't have a standard
way for a user to examine or recall the policy of an application,
using whatever API they wanted. If every module implements its own
policy store separately, such a UI would be extremely difficult to
build.


Yes, you are most definitely right. We only provided a default policy,
but we also need a way to get feedback from the user about his/her
preferences.

One thing that is going to get problematic is what happens when
one updates a piece of software and the policy does not match
anymore. Since it is a pretty coarse grained policy, it should not
be an issue!

In any case, the user preference could be stored and managed by
libwsm and modules would only be called if no user preference is
found.


 From what I read, Wayland Security Modules didn't seem to even provide
that as a baseline, which is why I believe they're tackling the
problem from the wrong angle.


We attacked the problem from a UX point of view and then a distro
point of view. The custom configuration was a bit left on the side
since experimented users could write their own file and more novice
users would likely be more than OK with a runtime GUI to manage
the rights and allow granting privileges when needed.

We most definitely do not wish to ever have something as annoying
as the UAC in Linux, constantly asking the user for permissions on
things the user has no understanding about.

I really think that the 4 levels proposed by libwsm make a lot of sense
to reduce annoyance as much as possible [2]

[1] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
[2] https://github.com/mupuf/libwsm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Daniel Stone]

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 they want to see, rather than requiring the entire
>> world be perfectly isolated and abstracted along inter-module
>> boundaries, freely mix-and-matchable.
>
> I should rephrase: it's against the spirit of Unix. Simple, composable
> tools, that Do One Thing And Do It Well, is the Unix way. Our desktop
> environments needn't and shouldn't be much different.

And yet the existence and dominant popularity of large integrated
environments (historically beginning with Emacs) suggests that the
pithy summary is either wrong, or no longer applicable. Ditto the
relative successes of Plan 9 and microkernels compared to other OSes.

>> Secondly, you talk about introducing all these concepts and protocols
>> as avoiding complexity. Nothing could be further from the case. That
>> X11 emulates this model means that it has Xinerama, XRandR,
>> XF86VidMode, the ICCCM, and NetWM/EWMH, as well as all the various
>> core protocols. You're not avoiding complexity, but simultaneously
>> shifting and avoiding it. You're not avoiding policy to create
>> mechanism; the structure and design of the mechanism is a policy in
>> itself.
>
> I disagree. I think this is just a fundamental difference of opinion.

I really do not see how you can look at ICCM/EWMH and declare it to be
a victory for simplicity, and ease of implementation.

>> Thirdly, it's important to take a step back. 'Wayland doesn't support
>> middle-button primary selections' is a feature gap compared to X11;
>> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
>> the forest of user-visible behaviour for the trees of creating
>> protocol.
>
> I think you're missing what users are actually using. You'd be surprised
> at how many power users are comfortable working with tools like xrandr
> and scripting their environments. This is about more than just
> xrandr-like support, too. There's definitely a forest of people using
> screen capture for live streaming, for instance.

Yes, screen capture is vital to have.

Providing some of the functionality (application fullscreening,
including to potentially different sizes/modes than are currently set;
user display control) that RandR does, is also vital. Providing an
exact clone of XRandR ('let's provide one protocol that allows any
arbitrary application to do what it likes'), much less so.

I also posit that anyone suggesting that providing the full XRandR
suite to arbitrary users makes implementation more simple, has never
been on the sharp end of that implementation.

>> Fourthly, I think you misunderstand the role of what we do. If you
>> want to design and deploy a modular framework for Legoing your own
>> environment together, by all means, please do that. Give it a go, see
>> what falls out, see if people creating arbitrary external panels and
>> so find it useful, and then see if you can convince the others to
>> adopt it. But this isn't really the place for top-down design where we
>> dictate how all environments based on Wayland shall behave.
>
> I've already seen this. It's been around for a long time. I don't know
> if you live in a "desktop environment bubble", but there's a LOT of this
> already in practice in the lightweight WM world. Many, many users, are
> using software like i3 and xmonad and herbstluftwm and openbox and so on
> with composable desktop tools like dmenu and i3bar and lemonbar and so
> on _today_.

Yes I know, as a former long-term Awesome/OpenBox/etc etc etc etc etc user.

> This isn't some radical experiment in making a composable
> desktop. It's already a well proven idea, and it works great.

Again, I don't know in what parallel universe ICCCM+EWMH are 'great', but OK.

> I would
> guess that the sum of people who are using a desktop like this
> perhaps outnumbers the total users of, say, enlightenment. I'm just
> bringing the needs of this group forward.

I would suggest the total number of users of these 'power'
environments allowing full flexibility and arbitrary external control
(but still via entirely standardised protocols), is several orders of
magnitude than the combined total of Unity, GNOME and KDE, but I don't
think this thread really needs any more value judgements.

My point is that there is no solution for this existing _on Wayland_
today, something which I would've thought to be pretty inarguable,
since that's what this entire thread is ostensibly about. I know full
well that this exists on X11, and that there are users of the same,
but again, you are talking about creating the same functionality as a
generic Wayland protocol, so it's pretty obvious that it doesn't exist
today.

What I was trying to get at, before this devolved into angrily trying
to create 

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 isolated and abstracted along inter-module
> boundaries, freely mix-and-matchable.

I should rephrase: it's against the spirit of Unix. Simple, composable
tools, that Do One Thing And Do It Well, is the Unix way. Our desktop
environments needn't and shouldn't be much different.

> Secondly, you talk about introducing all these concepts and protocols
> as avoiding complexity. Nothing could be further from the case. That
> X11 emulates this model means that it has Xinerama, XRandR,
> XF86VidMode, the ICCCM, and NetWM/EWMH, as well as all the various
> core protocols. You're not avoiding complexity, but simultaneously
> shifting and avoiding it. You're not avoiding policy to create
> mechanism; the structure and design of the mechanism is a policy in
> itself.

I disagree. I think this is just a fundamental difference of opinion.

> Thirdly, it's important to take a step back. 'Wayland doesn't support
> middle-button primary selections' is a feature gap compared to X11;
> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
> the forest of user-visible behaviour for the trees of creating
> protocol.

I think you're missing what users are actually using. You'd be surprised
at how many power users are comfortable working with tools like xrandr
and scripting their environments. This is about more than just
xrandr-like support, too. There's definitely a forest of people using
screen capture for live streaming, for instance.

> Fourthly, I think you misunderstand the role of what we do. If you
> want to design and deploy a modular framework for Legoing your own
> environment together, by all means, please do that. Give it a go, see
> what falls out, see if people creating arbitrary external panels and
> so find it useful, and then see if you can convince the others to
> adopt it. But this isn't really the place for top-down design where we
> dictate how all environments based on Wayland shall behave.

I've already seen this. It's been around for a long time. I don't know
if you live in a "desktop environment bubble", but there's a LOT of this
already in practice in the lightweight WM world. Many, many users, are
using software like i3 and xmonad and herbstluftwm and openbox and so on
with composable desktop tools like dmenu and i3bar and lemonbar and so
on _today_. This isn't some radical experiment in making a composable
desktop. It's already a well proven idea, and it works great. I would
guess that the sum of people who are using a desktop like this
perhaps outnumbers the total users of, say, enlightenment. I'm just
bringing the needs of this group forward.

Some of your email is just griping about the long life of this thread,
and you're right. I think I've got most of what I wanted from this
thread, I'm going to start proposing some protocols in new threads next.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

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 of your output and
> > > input devices and so on, and it should be responsible for making them
> > > available.
> > 
> > I didn't say the display server shouldn't be the one exposing such an
> > API, I just think it is a bad idea to duplicate every display server
> > agnostic API for every possible display server protocol.
> 
> Do you foresee GNOME on Mir ever happening? We're trying to leave X
> behind here. There won't be a Wayland replacement for a while. The
> Wayland compositor has ownership over these resources and the Wayland
> compositor is the one managing these resources - and it speaks the
> Wayland protocol, which is extensible.

GNOME's mutter already work as being a compositor for two separate
protocols: X11 and Wayland. Whenever possible, I by far prefer to
deprecate the way replacing it with a display server protocol agnostic
solution, than having duplicate implementation for every such thing.

> 
> > > I know that Gnome folks really love their DBus, but I don't think that
> > > it makes sense to use it for this. Not all of the DEs/WMs use dbus and
> > > it would be great if the tools didn't have to know how to talk to it,
> > > but instead had some common way of getting pixels from the compositor.
> > 
> > So if you have a compositor or a client that wants to support three
> > display server architectures, it needs to implement all those three
> > API's separately? Why can't we provide an API ffmpeg etc can use no
> > matter if the display server happens to be the X server, sway or
> > Unity-on-Mir?
> 
> See above

Most if not all clients will for the forseeable future most likely need
to support at least three protocols on Linux: X11, Wayland and Mir. I
don't see any of these going away any time soon, and I don't see any
reason to have three separate interfaces doing exactly the same thing.

> 
> > I don't see the point of not just using D-Bus just because you aren't
> > using it yet. It's already there, installed on your system, it's already
> > used by various other parts of the stack, and it will require a lot less
> > effort by clients and servers if they they want to support more than
> > just Wayland.
> 
> 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 on this and I
> don't want it to devolve into a flamewar - I'm just not imposing either
> side of the dbus/systemd argument on my users.
> 
> > Pinos communicates via D-Bus, but pixels/frames are of course never
> > passed directly, but via shared memory handles. What a screen
> > cast/remote desktop API would do is more or less to start/stop a pinos
> > stream and optionally inject events, and let the client know what stream
> > it should use.
> 
> Hmm. Again going back to "I don't want to make the dbus decision for my
> users", I would prefer to find a solution that's less dependent on it,
> though I imagine taking inspiration from Pinos is quite reasonable.

We are not going to reimplement anything like Pinos via Wayland
protocols, so any client/compositor that want to do anything related to
stream casting (anything that doesn't just make the content end up
directly on the filesystem) will either need to reimplement their own
private solution, or depend on something like Pinos which will itself
depend on D-Bus.

> 
> > Sorry, I don't see how you make the connection between "Wayland" and
> > "screen capture" other than that it may be implemented in the same
> > process. Wayland is meant to be used by clients to be able to pass
> > content to  and receive input from the display server. It's is not
> > intended to be a catch-all IPC replacing D-Bus.
> 
> DBus is not related to Wayland. DBus is not _attached_ to Wayland. DBus
> and Wayland are seperate, unrelated protocols and solving Wayland
> problems with DBus is silly.

So is screen casting/recording/sharing. It's a feature of a compositor,
not a feature of Wayland. Screen casting in the way you describe (pass
content to some client) will most likely have its frames passed via
D-Bus, so you'd still force your user to use D-Bus anyway.


Jonas

> 
> --
> Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Daniel Stone]

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 this point you're heading towards,
> though: e doesn't intend to suit everyone's needs.

If a compositor implementation can never be sufficient to express
peoples' needs, how could an arbitrary protocol be better? Same
complexity problem.

(And, as far as the 'but what if a compositor implementation isn't
good' argument goes - don't use bad compositors.)

Cheers,
Daniel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Drew DeVault]

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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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/?
> p=kwayland.git=blob=8bc106c7c42a40f71dad9a884824a7a9899e7b2f=818e320bd99867ea9c831edfb68c9671ef7dfc47=src
> %2Fclient%2Fprotocols%2Fserver-decoration.xml

Excellent. The protocol looks like it'll do just fine.

> I think especially for compositors like sway that can be very helpful. For Qt 
> we implemented support in our QPT plugin for Plasma. So if sway wants to use 
> it I can give you pointers on how to use it in your own QPT plugin (if you 
> don't have one yet how to create it) and to use it to force QtWayland to not 
> use the client side decorations.

I would love to see something like that. Can we work on a model that
would avoid making users install qt to install Sway? Honestly I'd like
to just set an environment variable to turn off CSD where possible, for
both Qt and GTK. I'm still trying to avoid forcing a toolkit on users.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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
> %2Fclient%2Fprotocols%2Foutput-management.xml
> 
> and
> 
> https://quickgit.kde.org/?
> p=kwayland.git=blob=747fc264b7e6a40a65a0a04464c2c98036a84f0f=818e320bd99867ea9c831edfb68c9671ef7dfc47=src
> %2Fclient%2Fprotocols%2Foutputdevice.xml
> 
> It's designed for our specific needs in Plasma. If it's useful for others, we 
> are happy to share and collaborate.

It looks like something I could use in Sway. I like it. I'm going to see
how well it integrates with Sway and probably write a command line tool
to interface with it. I think that it would be useful to put this under
the permissions system, though, once that's put together.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 protocol exists) unless it is executed by the compositor. the compositor
> can do whatever it deems "necessary" to ensure it executes only 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 /proc/cmdline, from which
we can get the binary path. We can even look at /proc/exe and produce a
checksum of it, so that programs become untrusted as soon as they
change.

> i know - but for just capturing screencasts, adding watermarks etc. - all you
> need is to store a stream - the rest can be post-processed.

Correct, if you record to a file, you can deal with it in post. But
there are other concerns, like what output format you'd like to use and
what encoding quality you want to use to consider factors like disk
space, cpu usage, etc. And there still is the live streaming use-case,
which we should support and which your solution does not address.

> why do we need the fullscreen shell? that was intended for environments where
> apps are only ever fullscreen from memory. xdg shell has the ability for a
> window to go fullscreen (or back to normal) this should do just fine. :) sure 
> -
> let's talk about this stuff - fullscreening etc.

I've been mixing up fullscreen-shell with that one thing in xdg-shell.
My bad.

> let's talk about the actual apps surfaces and where they go - not
> configuration of outputs. :)

No, I mean, that's what I'm getting at. I don't want to talk about that
because it doesn't make sense outside of e. On Sway, the user is putting
their windows (fullscreen or otherwise) on whatever output they want
themselves. There aren't output roles. Outputs are just outputs and I
intend to keep it that way.

> > Troublemaking software is going to continue to make trouble. Further
> > news at 9. That doesn't really justify making trouble for users as well.
> 
> 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 this point you're heading towards,
though: e doesn't intend to suit everyone's needs.

> > Here's the wayland screenshot again for comparison:
> > 
> > https://sr.ht/Ai5N.png
> > 
> > Most apps are fine with being told what resolution to be, and they
> > _need_ to be fine with this for the sake of my sanity. But I understand
> > that several applications have special concerns that would prevent this
> 
> but for THEIR sanity, they are not fine with it. :)

Nearly all toolkits are entirely fine with being any size, at least
above some sane minimum. A GUI that cannot deal with being a
user-specified size is a poorly written GUI.

> no. this has nothing to do with floating. this has to do with minimum and in
> this case especially - maximum sizes. it has NOTHING to do with floating. you
> are conflating sizing with floating because floating is how YOU HAPPEN to want
> to deal with it.

Fair. Floating is how I would deal with it. But maybe I'm missing
something: where does the min/max size hints come from? All I seem to
know of is the surface geometry request, which isn't a hint so much as
it's something every single app does. If I didn't ignore it, all windows
would be fucky and the tiling layout wouldn't work at all. Is there some
other hint coming from somewhere I'm not aware of?

> you COULD deal with it as i described - pad out the area or
> scale retaining aspect ratio - allow user to configure the response. if i had 
> a
> small calculator on the left and something that can size up on the right i
> would EXPECt a tiling wm to be smart and do:
> 
> +---++
> |   ||
> |:::||
> |:::||
> |:::||
> |   ||
> +---++

Eh, this might be fine for a small number of windows, and maybe even is
the right answer for Sway. I'm worried about it happening for most
windows and I don't want to encourage people to make their applications
locked into one aspect ratio and unfriendly to tiling users.

> > What I really want is _users_ to have control. I don't like it that
> > compositors are forcing solutions on them that doesn't allow them to be
> > in control of how their shit works.
> they can patch their compositors if they want. if you are forcing users to
> write scripts you are already forcing them to "learn to code" in a simple way.
> would it not be best to try and make things work without needing 
> scripts/custom
> code per user and have features/modes/logic that "just work" ?

There's a huge difference between the 

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 gives the compositor that.

Understood. I'm on board.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 responsible for making them
> > available.
> 
> I didn't say the display server shouldn't be the one exposing such an
> API, I just think it is a bad idea to duplicate every display server
> agnostic API for every possible display server protocol.

Do you foresee GNOME on Mir ever happening? We're trying to leave X
behind here. There won't be a Wayland replacement for a while. The
Wayland compositor has ownership over these resources and the Wayland
compositor is the one managing these resources - and it speaks the
Wayland protocol, which is extensible.

> > I know that Gnome folks really love their DBus, but I don't think that
> > it makes sense to use it for this. Not all of the DEs/WMs use dbus and
> > it would be great if the tools didn't have to know how to talk to it,
> > but instead had some common way of getting pixels from the compositor.
> 
> So if you have a compositor or a client that wants to support three
> display server architectures, it needs to implement all those three
> API's separately? Why can't we provide an API ffmpeg etc can use no
> matter if the display server happens to be the X server, sway or
> Unity-on-Mir?

See above

> I don't see the point of not just using D-Bus just because you aren't
> using it yet. It's already there, installed on your system, it's already
> used by various other parts of the stack, and it will require a lot less
> effort by clients and servers if they they want to support more than
> just Wayland.

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 on this and I
don't want it to devolve into a flamewar - I'm just not imposing either
side of the dbus/systemd argument on my users.

> Pinos communicates via D-Bus, but pixels/frames are of course never
> passed directly, but via shared memory handles. What a screen
> cast/remote desktop API would do is more or less to start/stop a pinos
> stream and optionally inject events, and let the client know what stream
> it should use.

Hmm. Again going back to "I don't want to make the dbus decision for my
users", I would prefer to find a solution that's less dependent on it,
though I imagine taking inspiration from Pinos is quite reasonable.

> Sorry, I don't see how you make the connection between "Wayland" and
> "screen capture" other than that it may be implemented in the same
> process. Wayland is meant to be used by clients to be able to pass
> content to  and receive input from the display server. It's is not
> intended to be a catch-all IPC replacing D-Bus.

DBus is not related to Wayland. DBus is not _attached_ to Wayland. DBus
and Wayland are seperate, unrelated protocols and solving Wayland
problems with DBus is silly.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Daniel Stone]

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 however they see fit and it's their god damn right to. Anything
> else is against the spirit of free software.

I only have a couple of things to add, since this thread is so long,
so diverse, and so shouty, that it's long past the point of
usefulness.

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 isolated and abstracted along inter-module
boundaries, freely mix-and-matchable.

Secondly, you talk about introducing all these concepts and protocols
as avoiding complexity. Nothing could be further from the case. That
X11 emulates this model means that it has Xinerama, XRandR,
XF86VidMode, the ICCCM, and NetWM/EWMH, as well as all the various
core protocols. You're not avoiding complexity, but simultaneously
shifting and avoiding it. You're not avoiding policy to create
mechanism; the structure and design of the mechanism is a policy in
itself.

Thirdly, it's important to take a step back. 'Wayland doesn't support
middle-button primary selections' is a feature gap compared to X11;
'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
the forest of user-visible behaviour for the trees of creating
protocol.

Fourthly, I think you misunderstand the role of what we do. If you
want to design and deploy a modular framework for Legoing your own
environment together, by all means, please do that. Give it a go, see
what falls out, see if people creating arbitrary external panels and
so find it useful, and then see if you can convince the others to
adopt it. But this isn't really the place for top-down design where we
dictate how all environments based on Wayland shall behave.

I don't really hold out hope for this thread, but would be happy to
pick up separate threads on various topics, e.g. screen
capture/streaming to external apps.

Cheers,
Daniel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 require to fork the process directly from compositor and provide a
> socketpair fd to this process and THAT fd could have extra capabilities
> attached to the wl protocol. i would do nothing else because as a compositor i
> cannot be sure what i am executing. i'd hand over the choice of being able to
> execute this tool to the user to say ok to and not just blindly execute
> anything i like.

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
you elaborate on how this changes things? I should also mention that I
don't really see the sort of security goals Wayland has in mind as
attainable until we start doing things like containerizing applications,
in which case we can elimitate entire classes of problems from this
design.

> all a compositor has to do is be able to capture a video stream to a file. you
> can ADD watermarking, sepia, and other effects later on in a video editor. 
> next
> you'll tell me gimp is incapable of editing image files so we need 
> programmatic
> access to a digital cameras ccd to implement effects/watermarking etc. on
> photos...

I'll remind you again that none of this supports the live streaming
use-case.

> > currently possible with ffmpeg. How about instead we make a simple
> > wayland protocol extension that we can integrate with ffmpeg and OBS and
> > imagemagick and so on in a single C file.
> 
> i'm repeating myself. there are bigger fish to fry.

I'm repeating myself. Fry whatever fish you want and backlog this fish.

> eh? ummm that is what happens - unless you close the lid, then internal 
> display
> is "disconnected".

I'm snipping out a lot of the output configuration related stuff from
this response. I'm not going to argue very hard for a common output
configuration protocol. I've been trying to change gears on the output
discussion towards a discussion around whether or not the
fullscreen-shell protocol supports our needs and whether or how it needs
to be updated wrt permissions. I'm going to continue to omit large parts
of your response that I think are related to the resistance to output
configuration, let me know if there's something important I'm dropping
by doing so.

> a protocol with undefined metadata is not a good protocol. it's now goes blobs
> of data that are opaque except to specific implementations., this will mean
> that other implementations eventually will do things like strip it out or 
> damage
> it as they don't know what it is nor do they care.

It doesn't have to be undefined metadata. It can just be extensions. A
protocol with extensions built in is a good protocol whose designers had
foresight, kind of like the Wayland protocol we're all already making
extensions for.

> but it isn't the user - it's some game you download that you cannot alter the
> code or behaviour of that then messes everything up because its creator only
> ever had a single monitor and didn't account for those with 2 or 3.

But it _is_ the user. Let the user configure what they want, however
they want, and make it so that they can both do this AND deny crappy
games the right to do it as well. This applies to the entire discussion
broadly, not necessarily just to the output configuration bits (which I
retract).

> because things like output configuration i do not see as needing a common
> protocol. in fact it's desirable to not have one at all so it cannot be abused
> or cause trouble.

Troublemaking software is going to continue to make trouble. Further
news at 9. That doesn't really justify making trouble for users as well.

> > In practice the VAST majority of our users are going to be using one or
> > more rectangular displays. We shouldn't cripple what they can do for the
> > sake of the niche. We can support both - why do we have to hide
> > information about the type of outputs in use from the clients? It
> > doesn't make sense for an app to get fullscreened in a virtual reality
> > compositor, yet we still support that. Rather than shoehorning every
> > design to meet the least common denominator, we should be flexible.
> 
> they are not crippled. that's the point. in virtual reality fullscreen makes
> sense as a "take over thew world", not take over the output to one eye.for
> monitors on a desktop it makes sense to take over that monitor but not others.
> so it depends on context and the compositors job is to interpret/manage/deal
> with that context.

I don't really understand what you're getting at here.

> sorry. neither in x11 nor in wayland does a wm/compositor just have the 
> freedom
> to resize a window to any size it likes WITHOUT CONSEQUENCES. in x11 min/max
> size hints tell the wm the range of sizes a window can be sensibly drawn/laid
> out 

Re: Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

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 this. In general, my opinion is that it is
> > completely pointless to add Wayland protocols for things that has
> > nothing to do with Wayland what so ever; we have other display protocol
> > agnostic methods for that that fits much better.
> 
> I think these features have a lot to do with Wayland, and I still
> maintain that protocol extensions make sense as a way of doing it. I
> don't want to commit my users to dbus or something similar and I'd
> prefer if I didn't have to make something unique to sway. It's probably
> going to be protocol extensions for some of this stuff and I think it'd
> be very useful for the same flexibility to be offered by other
> compositors.
> 
> > As a rule of thumb, whether a feature needs a Wayland protocol or not,
> > one can consider whether a client needs to reference a client side
> > object (such as a surface) on the server. If it needs it, we should add
> > a Wayland protocol; otherwise not. Another way of seeing it would be
> > "could this be shared between Wayland/X11/Mir/... then don't do it in
> > any of those".
> 
> 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 responsible for making them
> available.

I didn't say the display server shouldn't be the one exposing such an
API, I just think it is a bad idea to duplicate every display server
agnostic API for every possible display server protocol.

> 
> > > - Screen capture
> > Why would this ever be a Wayland protocol? If a client needs to capture
> > its own content it doesn't need to ask the compositor; otherwise it's
> > the job of the compositor. If there needs to be a complex pipeline setup
> > that adds sub titles, muxing, sound effects and what not, we should make
> > use of existing projects that intend to create inter-process video
> > pipelines (pinos[0] for example).
> > 
> > FWIW, I believe remote desktop/screen sharing support partly falls under
> > this category as well, with the exception that it may need input event
> > injection as well (which of course shouldn't be a Wayland protocol).
> > 
> > As a side note, for GNOME, I have been working on a org.gnome prefixed
> > D-Bus protocol for remote desktop that enables the actual remote desktop
> > things to be implemented in a separate process by providing pinos
> > streams, and I believe that at some point it would be good to have a
> > org.freedesktop.* (or equivalent) protocol doing that in a more desktop
> > agnostic way. Such a protocol could just as well be read-only, and
> > passed to something like ffmpeg (maybe can even pipe it from gst-launch
> > directly to ffmpeg if you so wish) in order to do screen recording.
> 
> I know that Gnome folks really love their DBus, but I don't think that
> it makes sense to use it for this. Not all of the DEs/WMs use dbus and
> it would be great if the tools didn't have to know how to talk to it,
> but instead had some common way of getting pixels from the compositor.

So if you have a compositor or a client that wants to support three
display server architectures, it needs to implement all those three
API's separately? Why can't we provide an API ffmpeg etc can use no
matter if the display server happens to be the X server, sway or
Unity-on-Mir?

I don't see the point of not just using D-Bus just because you aren't
using it yet. It's already there, installed on your system, it's already
used by various other parts of the stack, and it will require a lot less
effort by clients and servers if they they want to support more than
just Wayland.

> 
> I haven't heard of Pinos before, but brief searches online make it look
> pretty useful for this purpose. I think it can be involved here.
> 

Pinos communicates via D-Bus, but pixels/frames are of course never
passed directly, but via shared memory handles. What a screen
cast/remote desktop API would do is more or less to start/stop a pinos
stream and optionally inject events, and let the client know what stream
it should use.

> 
> > I don't think we should start writing Wayland protocols for things that
> > has nothing to do with Wayland, only because the program where it is
> > going to be implemented in may already may be doing Wayland things.
> > There simply is no reason for it.
> > 
> > We should simply use the IPC system that we already have that we already
> > use for things like this (for example color management, inter-process
> > video pipelines, geolocation, notifications, music player control, audio
> > device discovery, accessibility, etc.).
> 
> Most of what you mentioned (geolocation, notifications, music control,
> audio device discovery) have anything to do with Wayland. Why would they
> 

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 this. In general, my opinion is that it is
> completely pointless to add Wayland protocols for things that has
> nothing to do with Wayland what so ever; we have other display protocol
> agnostic methods for that that fits much better.

I think these features have a lot to do with Wayland, and I still
maintain that protocol extensions make sense as a way of doing it. I
don't want to commit my users to dbus or something similar and I'd
prefer if I didn't have to make something unique to sway. It's probably
going to be protocol extensions for some of this stuff and I think it'd
be very useful for the same flexibility to be offered by other
compositors.

> As a rule of thumb, whether a feature needs a Wayland protocol or not,
> one can consider whether a client needs to reference a client side
> object (such as a surface) on the server. If it needs it, we should add
> a Wayland protocol; otherwise not. Another way of seeing it would be
> "could this be shared between Wayland/X11/Mir/... then don't do it in
> any of those".

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 responsible for making them
available.

> > - Screen capture
> Why would this ever be a Wayland protocol? If a client needs to capture
> its own content it doesn't need to ask the compositor; otherwise it's
> the job of the compositor. If there needs to be a complex pipeline setup
> that adds sub titles, muxing, sound effects and what not, we should make
> use of existing projects that intend to create inter-process video
> pipelines (pinos[0] for example).
> 
> FWIW, I believe remote desktop/screen sharing support partly falls under
> this category as well, with the exception that it may need input event
> injection as well (which of course shouldn't be a Wayland protocol).
> 
> As a side note, for GNOME, I have been working on a org.gnome prefixed
> D-Bus protocol for remote desktop that enables the actual remote desktop
> things to be implemented in a separate process by providing pinos
> streams, and I believe that at some point it would be good to have a
> org.freedesktop.* (or equivalent) protocol doing that in a more desktop
> agnostic way. Such a protocol could just as well be read-only, and
> passed to something like ffmpeg (maybe can even pipe it from gst-launch
> directly to ffmpeg if you so wish) in order to do screen recording.

I know that Gnome folks really love their DBus, but I don't think that
it makes sense to use it for this. Not all of the DEs/WMs use dbus and
it would be great if the tools didn't have to know how to talk to it,
but instead had some common way of getting pixels from the compositor.

I haven't heard of Pinos before, but brief searches online make it look
pretty useful for this purpose. I think it can be involved here.

> > - Output configuration
> 
> This has nothing to do with Wayland as well. If there is any need for
> various compositors to support third party output configuration, at
> least make it display protocol agnostic (D-Bus) so that it the doesn't
> have to be one implementation in each layer for each display protocol
> when there is actually no point of doing so.

I'm dropping the output configuration protocols that I initially wanted
to make, I've come around. I think we just need to rethink fullscreen
requests to work with the permission model we come up with.

> > - More detailed surface roles (should it be floating, is it a modal,
> >   does it want to draw its own decorations, etc)
> 
> Sounds like a job for a xdg_* protocol. However, I think we need to
> first settle on a bare minimum protocol, in order to be able to
> stabalize anything. This bare minimum protocol needs allows for
> extendability making it possible to add things like negotiating how
> decorations are drawn etc. The idea is that xdg_shell v6 will allow
> this.
> 
> Of course we can add xdg_shell extensions already though (i.e. stand
> alone protocol extension that extends xdg_shell).

This sounds reasonable.

> > - Input device configuration
> 
> Same as output configuration. There simply is no valid reason for adding
> a Wayland protocol for it.

Same as output configuraiton, I've come around and we should probably
drop this, though again with the constraint that we should tweak things
like pointer-constraints to work with the permissions model.

> I don't think we should start writing Wayland protocols for things that
> has nothing to do with Wayland, only because the program where it is
> going to be implemented in may already may be doing Wayland things.
> There simply is no reason for it.
> 
> We should simply use the IPC system that we already have that we already
> use for things like this (for example color management, 

Re: Collaboration on standard Wayland protocol extensions

[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 Giulio's proposal makes sense because it could be used to
> both grant and revoke rights on the fly.

I think both solutions have similar merit and I don't feel strongly
about either one.

> >No, the compositor can remember your choice.
> 
> So, you would be asking users to click on "I agree" and "remember my choice"
> every time they set up a computer then :D Not nearly as bad, but still bad.

Well, I imagine we'd store their choices in a file somewhere. They can
bring that file along for the ride.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

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
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:

I'm just going to put down my own personal thoughts on these. I mostly
agree with Carsten on all of this. In general, my opinion is that it is
completely pointless to add Wayland protocols for things that has
nothing to do with Wayland what so ever; we have other display protocol
agnostic methods for that that fits much better.

As a rule of thumb, whether a feature needs a Wayland protocol or not,
one can consider whether a client needs to reference a client side
object (such as a surface) on the server. If it needs it, we should add
a Wayland protocol; otherwise not. Another way of seeing it would be
"could this be shared between Wayland/X11/Mir/... then don't do it in
any of those".

> 
> - Screen capture

Why would this ever be a Wayland protocol? If a client needs to capture
its own content it doesn't need to ask the compositor; otherwise it's
the job of the compositor. If there needs to be a complex pipeline setup
that adds sub titles, muxing, sound effects and what not, we should make
use of existing projects that intend to create inter-process video
pipelines (pinos[0] for example).

FWIW, I believe remote desktop/screen sharing support partly falls under
this category as well, with the exception that it may need input event
injection as well (which of course shouldn't be a Wayland protocol).

As a side note, for GNOME, I have been working on a org.gnome prefixed
D-Bus protocol for remote desktop that enables the actual remote desktop
things to be implemented in a separate process by providing pinos
streams, and I believe that at some point it would be good to have a
org.freedesktop.* (or equivalent) protocol doing that in a more desktop
agnostic way. Such a protocol could just as well be read-only, and
passed to something like ffmpeg (maybe can even pipe it from gst-launch
directly to ffmpeg if you so wish) in order to do screen recording.

> - Output configuration

This has nothing to do with Wayland as well. If there is any need for
various compositors to support third party output configuration, at
least make it display protocol agnostic (D-Bus) so that it the doesn't
have to be one implementation in each layer for each display protocol
when there is actually no point of doing so.

> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)

Sounds like a job for a xdg_* protocol. However, I think we need to
first settle on a bare minimum protocol, in order to be able to
stabalize anything. This bare minimum protocol needs allows for
extendability making it possible to add things like negotiating how
decorations are drawn etc. The idea is that xdg_shell v6 will allow
this.

Of course we can add xdg_shell extensions already though (i.e. stand
alone protocol extension that extends xdg_shell).

> - Input device configuration

Same as output configuration. There simply is no valid reason for adding
a Wayland protocol for it.

> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.

I don't think we should start writing Wayland protocols for things that
has nothing to do with Wayland, only because the program where it is
going to be implemented in may already may be doing Wayland things.
There simply is no reason for it.

We should simply use the IPC system that we already have that we already
use for things like this (for example color management, inter-process
video pipelines, geolocation, notifications, music player control, audio
device discovery, accessibility, etc.).


Jonas

> 
> --
> Drew DeVault
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> 

Re: Collaboration on standard Wayland protocol extensions

[Peter Hutterer]

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
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration

a comment on the last point: input device configuration is either extremely
simple ("I want tapping enabled") or complex ("This device needs feature A
when condition B is met"). There is very little middle ground.

as a result, you either have some generic protocol that won't meet the niche
cases or you have a complex protocol that covers all the niche cases but
ends up being just a shim between the underlying implementation and the
compositor. Such a layer provides very little benefit but restricts what the
compositor can add in the future. It's not a good idea, imo.

Cheers,
   Peter

> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-28  4:35 PM, Emmanuele Bassi wrote:
> If you want to add additional stuff on top of a live stream, use
> something with a programmable pipeline that can add effects to the
> stream coming from the compositor. Why do we need negotiation, or user
> interation, or exchange of metadata for this stuff?

The stream isn't coming from the compositor. That's the point. It needs
to be. However, providing programmable access to that stream is a
security concern, so it should be given only to certain privledged
clients.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Emmanuele Bassi]

Hi;

On 28 March 2016 at 15:55, Drew DeVault  wrote:

> You're still not grasping the scope of this. I want you to run this
> command right now:
>
> man ffmpeg-all
>
> Just read it for a while. You're delusional if you think you can
> feasibly implement all of these features in the compositor. Do you
> honestly want your screen capture tool to be able to add a watermark?
> How about live streaming, some people add a sort of extra UI to read off
> donations and such. The scope of your screen capture tool is increasing
> at an alarming rate if you intend to support all of the features
> currently possible with ffmpeg. How about instead we make a simple
> wayland protocol extension that we can integrate with ffmpeg and OBS and
> imagemagick and so on in a single C file.

Wait, what?

Why do we need an extension protocol for Wayland to add stuff to screen casts?

If you want to add watermarks, use a video editor on the output file.

If you want to add additional stuff on top of a live stream, use
something with a programmable pipeline that can add effects to the
stream coming from the compositor. Why do we need negotiation, or user
interation, or exchange of metadata for this stuff?

[…]

This thread is rapidly approaching escape velocity from all the
architecture astronauting…

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-28 11:03 PM, Carsten Haitzler wrote:
> should we? is it right to create yet another rsecurity model in userspace
> "quickly" just to solve things that dont NEED solving at least at this point.

I don't think that the protocol proposed in other branches of this
thread is complex or short sighted. Can you hop on that branch and
provide feedback?

> adding watermarks can be done after encoding as another pass (encode in high
> quality). hell watermarks can just be a WINDOW (surface) on the screen. you
> don't need options. ass for audio - not too hard to do along with it. just
> offer to record an input device - and choose (input can be current mixed 
> output
> or a mic ... or both).

You're still not grasping the scope of this. I want you to run this
command right now:

man ffmpeg-all

Just read it for a while. You're delusional if you think you can
feasibly implement all of these features in the compositor. Do you
honestly want your screen capture tool to be able to add a watermark?
How about live streaming, some people add a sort of extra UI to read off
donations and such. The scope of your screen capture tool is increasing
at an alarming rate if you intend to support all of the features
currently possible with ffmpeg. How about instead we make a simple
wayland protocol extension that we can integrate with ffmpeg and OBS and
imagemagick and so on in a single C file.

> exactly what you describe is how e works out of the box. no sscripts needed.
> requiring people write script to do their screen configuration is just wrong.
> taking the position of "well i give up and won't bother and will just make my
> users write scripts instead" iss sticking your head in the sand and not 
> solving
> the problem. you are now asking everyone ELSE who writes a compositor to
> implement a protocol because YOU wont solve a problem that others have solved
> in a user friendly manner.

What if I want my laptop display to remain usable? Right now I'm docked
somewhere else and I actually do have this scenario - my laptop is one
of my working displays. How would I configure the difference between
these situations in your tool? What if I'm on a laptop with poorly
supported hardware (I've seen this before) where there's a limit on how
many outputs I can use at once? What if I want to write a script where I
put on a movie and it disables every output but my TV automatically? The
user is losing a lot of power here and there's no way you can satisfy
everyone's needs unless you make it programmable.

> > Base your desktop's tools on the common protocol, of course. Gnome
> > settings, KDE settings, arandr, xrandr, nvidia-settings, and so on, all
> > seem to work fine configuring your outputs with the same protocol today.
> > Yes, the protocol is meh and the implementation is a mess, but the
> > clients of that protocol aren't bad by any stretch of the imagination.
> 
> no tools. why do it? it's built in. in order for screen config "magic" to
> work  set of metadata  attached to screens. you can set priority (screens get
> numbers from highest to lowest priority at any given time allowing behaviour
> like your "primary" screen to migrate to an external one then migrate back 
> when
> external monitor is attached etc.) sure we can start having that metadata
> separate but then ALTERNATE TOOLS won't be able to configure it thus breaking
> the desktop environment not providing metadata and other settings associated
> with a display. this breaks functionality for users who then complain about
> things not working right AND then the compositor has to now deal with these
> "error cases" too because a foreign tool will be messing with its data/setup.

Your example has a pretty straightforward baseline - the "default"
profile. Even so, we can design the protocol to make the custom metadata
options visible to the tools, and the tools can then provide the user
with options to configure that as well.

> as above. i have seen screen configuration used and abused over the years 
> where
> i just do not want to have a protocol for messing around with it for any
> client. give them an inch and they'll take a mile.

Let them take a mile. _I_ want a mile. Here's an old quote that I think
is always relevant:

UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things.

> and that's perfectly fine - that is your choice. do not force your choice on
> other compositors. you can implement all the protocol you want in any way you
> want for your wm's tools.

Why do we have to be disjointed? We have a common set of problems and we
should strive for a common set of solutions.

> gnome does almost everything with dbus. they love dbus. a lot of gnome is
> centred around dbus. they likely will choose dbus to do this. likely. i
> personally wouldn't choose to use dbus.

Let's not speak for Gnome. They're copied on this thread, they'll speak
for themselves.

> > primary display? What about 

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-28  9:08 AM, Giulio Camuffo wrote:
> On this, see 
> https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html
> I have not been able to continue on that, but if you want to feel free
> to grab that proposal.

I looked through this protocol and it seems like it's a good start. We
should base our work on this.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-27 10:21 PM, Jasper St. Pierre wrote:
> I would rather the effort be spent making secure interfaces, exactly
> as you've described.

Agreed. I think it should be pretty straightforward:

Client->Server: What features do you support?
Server->Client: These privledged features are available.
Client->Server: I want this feature (nonblocking)
[compositor prompts user to agree]
Server->Client: Yes/no
[compositor enables the use of those protocols for this client]

I can start to write up some XML to describe this formally. We can take
some inspiration from the pointer-constraints protocol and I'll also
rewrite that protocol with this model in mind. Does anyone see anything
missing from this exchange?

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-28  2:13 PM, Carsten Haitzler wrote:
> yes but you need permission and that is handled at kernel level on a specific
> file. not so here. compositor runs as a specific user and so you cant do that.
> you'd have to do in-compositor security client-by-client.

It is different, but we should still find a way to do it. After all,
we're going to be in a similar situation eventually where we're running
sandboxed applications and the compositor is granting rights from the
same level of privledge as the kernel provides to root users (in this
case, the role is almost of a hypervisor and a guest).

> you wouldn't recreate ffmpeg. ffmpec produce libraries like avcodec. like a
> reasonable developer we'd just use their libraries to do the encoding - we'd
> capture frames and then hand off to avcodec (ffmpeg) library routines to do 
> the
> rest. ffmpeg doesnt need to know how to capture - just to do what 99% of its
> code is devoted to doing - encode/decode. :) that's rather simple. already we
> have decoding wrapped - we sit on top of either gstreamer, vlc or xine as the
> codec engine and just glue in output and control api's and events. encoding is
> just the same but in reverse. :) the encapsulation is simple.

True, that most of the work is in the avcodec. However, there's more to
it than that. The entire command line interface of ffmpeg would be
nearly impossible to build into the compositor effectively. With ffmpeg
I can capture x, flip it, paint it sepia, add a logo to the corner, and
mux it with my microphone and a capture of the speakers (thanks,
pulseaudio) and add a subtitle track while I'm at it. Read the ffmpeg
man pages. ffmpeg-all(1) is 23,191 lines long on my terminal (that's
just the command line interface, not avcodec). There's no way in hell
all of the compositors/DEs are going to be able to fulfill all of its
use cases, nor do I think we should be trying to.

Look at things like OBS. It lets you specify detailed encoding options
and composites a scene from multiple video sources and audio sources,
as well as letting the user switch between different scenes with
configurable transitions. It even lets you embed a web browser into the
final result! All of this with a nice GUI to top it off. Again, we can't
possibly hope to effectively implement all of this in the compositor/DE,
or the features of the other software that we haven't even thought of.
 
> the expectation is there won't be generic tools but desktop specific ones. the
> CURRENT ecosystem of tools exist because that is the way x was designed to
> work. thus the srate of software matches its design. wayland is different. 
> thus
> tools and ecosystem will adapt.

That expectation is misguided. I like being able to write a script to
configure my desktop layout between several presets. Here's an example -
a while ago, I used a laptop at work that could be plugged into a
docking station. I would close the lid and use external displays at my
desk. I wanted to automatically change the screen layout when I came and
went, so I wrote a script that used xrandr to do it. It detected when
there were new outputs plugged in, then disabled the laptop screen and
enabled+configured the two new screens in the correct position and
resolution. This was easy for me to configure to behave the way I wanted
because the tooling was flexible and cross-desktop. Sure, we could make
each compositor support it, but each one is going to do it differently
and in their own subtly buggy ways and with their own subset of the
total possible features and use-cases, and none of them are going to
address every possible scenario.

> as for output config - why would the desktops that already have their own 
> tools
> then want to support OTHER tools too? their tools integrate with their 
> settings
> panels and look and feel right and support THEIR policies.

Base your desktop's tools on the common protocol, of course. Gnome
settings, KDE settings, arandr, xrandr, nvidia-settings, and so on, all
seem to work fine configuring your outputs with the same protocol today.
Yes, the protocol is meh and the implementation is a mess, but the
clients of that protocol aren't bad by any stretch of the imagination.

> let me give you an example:
> 
> http://devs.enlightenment.org/~raster/ssetup.png
> 
> [snip]

This is a very interesting screenshot, and I hadn't considered this. I
don't think it's an unsolvable problem, though - we can make the
protocol flexible enough to allow compositor-specific metadata to be
added and configurable. These are the sorts of requirements I want to be
gathering to design this protocol with.

> no - we don't have to implement it as a protocol. enlightenment needs zero
> protocol. it's done by the compositor. the compositors own tool is simply a
> settings dialog inside the compositor itself. no protocol. not even a tool.
> it's the same as edit/tools -> preferences in most gui apps. its just a dialog
> the app shows to configure itself.

I currently 

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault  wrote:
> On 2016-03-27  4:41 PM, Jasper St. Pierre wrote:
>
> What are your specific concerns with it? I would tend to agree. I think
> that it's not bad as an implementation of this mechanic, but I agree
> that it's approaching the problem wrong. I think it would be wiser to
> start with how clients ask the compositor for permissions and how they
> receive them, then leave the details libwsm implements up to the
> compositors.
>
> I think a protocol extension would work just fine to implement a
> permission requesting/granting dialogue between clients and compositors.

That's what we should be doing, and that's why I'm not a huge fan of
WSM -- it provides a solution for the stuff that doesn't matter, and
doesn't make any progress on the part we need to tackle. I won't enjoy
using libwsm because it adds complexity and error cases (e.g. what
happens with no modules, like on a misconfigured system?), without
solving the actual problem.

Also, as I've mentioned in my emails before, APIs aren't exclusively
used through Wayland, they might also be on other systems like DBus,
which already has its own confusing policy system. It gets even worse
when protocols might cross both systems. So libwsm is already far in
the negative points bucket to me -- a Wayland-protocol centric
solution that ignores other IPCs and APIs, is configurable for no
purpose as far as I can tell, and still doesn't have an approachable
story about how it provides more security to the user.

I would rather the effort be spent making secure interfaces, exactly
as you've described.

> --
> Drew DeVault



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-27  4:41 PM, Jasper St. Pierre wrote:
> My opinion is still as follows: having seen how SELinux and PAM work
> out in practice, I'm skeptical of any "Security Module" which
> implements policy. The "module" part of it rarely happens, since
> people simply gravitate towards a standard policy. What's interesting
> to me isn't a piece of code that allows or rejects operations, it's
> the resulting UI *around* those operations and managing them, since
> that's really, at the end of the day, all the user cares about.

It has been done successfully, though. Consider the experience for iOS
and Android permissions. When an application needs to do something
sensitive, a simple dialog pops up explaining what it's asking for, and
allowing the user to consent once or forever. It's pretty simple and I
think we can accomplish something similar.

> It would be a significant failure to me if we didn't have a standard
> way for a user to examine or recall the policy of an application,
> using whatever API they wanted. If every module implements its own
> policy store separately, such a UI would be extremely difficult to
> build.

Ah, but here we are, all talking about it together. Let's make a
solution that works for all of us, then.

> From what I read, Wayland Security Modules didn't seem to even provide
> that as a baseline, which is why I believe they're tackling the
> problem from the wrong angle.

What are your specific concerns with it? I would tend to agree. I think
that it's not bad as an implementation of this mechanic, but I agree
that it's approaching the problem wrong. I think it would be wiser to
start with how clients ask the compositor for permissions and how they
receive them, then leave the details libwsm implements up to the
compositors.

I think a protocol extension would work just fine to implement a
permission requesting/granting dialogue between clients and compositors.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-28  8:55 AM, Carsten Haitzler wrote:
> i can tell you that screen capture is a security sensitive thing and likely
> won't get a regular wayland protocol. it definitely won't from e. if you can
> capture screen, you can screenscrape. some untrusted game you downloaded for
> free can start watching your internet banking and see how much money you have
> in which accounts where...

Right, but there are legitimate use cases for this feature as well. It's
also true that if you have access to /dev/sda you can read all of the
user's files, but we still have tools like mkfs. We just put them behind
some extra security, i.e. you have to be root to use mkfs.

> the simple solution is to build it into the wm/desktop itself as an explicit
> user action (keypress, menu option etc.) and now it can't be exploited as it's
> not pro grammatically available. :)
>
> i would imagine the desktops themselves would in the end provide video capture
> like they would stills.

I'd argue that this solution is far from simple. Instead, it moves *all*
of the responsibilities of your entire desktop into one place, and one
codebase. And consider the staggering amount of work that went into
making ffmpeg, which has well over 4x the git commits as enlightenment.

> > - Output configuration
> 
> why? currently pretty much every desktop provides its OWN output configuration
> tool that is part of the desktop environment. why do you want to re-invent
> randr here allowing any client to mess with screen config. after YEARS of 
> games
> using xvidtune and what not to mess up screen setups this would be a horrible
> idea. if you want to make a presentation tool that uses 1 screen for output 
> and
> another for "controls" then that's a matter of providing info that multiple
> displays exist and what type they may be (internal, external) and clients can
> tag surfaces with "intents" eg - this iss a control surface, this is an
> output/display surface. compositor will then assign them appropriately.

There's more than desktop environments alone out there. Not everyone
wants to go entirely GTK or Qt or EFL. I bet everyone on this ML has
software on their computer that uses something other than the toolkit of
their choice. Some people like piecing their system together and keeping
things lightweight, and choosing the best tool for the job. Some people
might want to use the KDE screengrab tool on e, or perhaps some other
tool that's more focused on doing just that job and doing it well. Or
perhaps there's existing tools like ImageMagick that are already written
into scripts and provide a TON of options to the user, which could be
much more easily patched with support for some standard screengrab
protocol than to implement all of its features in 5 different desktops.

We all have to implement output configuration, so why not do it the same
way and share our API? I don't think we need to let any client
manipulate the output configuration. We need to implement a security
model for this like all other elevated permissions.

Using some kind of intents system to communicate things like Impress
wanting to use one output for presentation and another for notes is
going to get out of hand quickly. There are just so many different
"intents" that are solved by just letting applications configure outputs
when it makes sense for them to. The code to handle this in the
compositor is going to become an incredibly complicated mess that rivals
even xorg in complexity. We need to avoid making the same mistakes
again. If we don't focus on making it simple, then in 15 years we're
going to be writing a new protocol and making a new set of mistakes. X
does a lot of things wrong, but the tools around it have a respect for
the Unix philosophy that we'd be wise to consider.

> > - More detailed surface roles (should it be floating, is it a modal,
> >   does it want to draw its own decorations, etc)
> 
> that seems sensible and over time i can imagine this will expand.

Cool. Suggestions for what sort of capability thiis protocol should
have, what kind of surface roles we will be looking at? We should
consider a few things. Normal windows, of course, which on compositors
like Sway would be tiled. Then there's floating windows, like
gnome-calculator, that are better off being tiled. Modals would be
something that pops up and prevents the parent window from being
interacted with, like some sort of alert (though preventing this
interactivity might not be the compositor's job). Then we have some
roles like dmenu would use, where the tool would like to arrange itself
(perhaps this would demand another permission?) Surfaces that want to be
fullscreen could be another. We should also consider additional settings
a surface might want, like negotiating for who draws the decorations or
whether or not it should appear in a taskbar sort of interface.

> > - Input device configuration
> 
> as above. i see no reason clients should be doing this. surface
> 

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

You're probably referring to my response when you say "GNOME does not
care about cross-platform apps doing privileged operations". My
response wasn't meant to be speaking on behalf of GNOME. These are my
opinions and mine alone.

My opinion is still as follows: having seen how SELinux and PAM work
out in practice, I'm skeptical of any "Security Module" which
implements policy. The "module" part of it rarely happens, since
people simply gravitate towards a standard policy. What's interesting
to me isn't a piece of code that allows or rejects operations, it's
the resulting UI *around* those operations and managing them, since
that's really, at the end of the day, all the user cares about.

It would be a significant failure to me if we didn't have a standard
way for a user to examine or recall the policy of an application,
using whatever API they wanted. If every module implements its own
policy store separately, such a UI would be extremely difficult to
build.

>From what I read, Wayland Security Modules didn't seem to even provide
that as a baseline, which is why I believe they're tackling the
problem from the wrong angle.

On Sun, Mar 27, 2016 at 1:50 PM, Martin Peres  wrote:
> On 27/03/16 23:34, 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,
>> Kwin, and wayland-devel) to collaborate on some shared protocol
>> extensions for doing a handful of common tasks such as display
>> configuration and taking screenshots. Life will be much easier for
>> projects like ffmpeg and imagemagick if they don't have to implement
>> compositor-specific code for capturing the screen!
>>
>> I want to start by establishing the requirements for these protocols.
>> Broadly speaking, I am looking to create protocols for the following
>> use-cases:
>>
>> - Screen capture
>> - Output configuration
>> - More detailed surface roles (should it be floating, is it a modal,
>>does it want to draw its own decorations, etc)
>> - Input device configuration
>>
>> I think that these are the core protocols necessary for
>> cross-compositor compatability and to support most existing tools for
>> X11 like ffmpeg. Considering the security goals of Wayland, it will also
>> likely be necessary to implement some kind of protocol for requesting
>> and granting sensitive permissions to clients.
>>
>> How does this list look? What sorts of concerns do you guys have with
>> respect to what features each protocol needs to support? Have I missed
>> any major protocols that we'll have to work on? Once we have a good list
>> of requirements I'll start writing some XML.
>>
>> --
>> Drew DeVault
>
>
> We had discussions about it years ago and here are the results of them:
> http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
>
> And here is the software we created, under the name "Wayland Security
> Modules":
> http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf
> https://github.com/mupuf/libwsm
>
> This approach has generally be liked by KDE, but not by Gnome who, last i
> heard, did not care about cross-platform apps doing privileged operations.
> This may have changed since they also decided to work on sandboxing
> (xdg-app) and implemented something like the following approach when they
> said they would never do because it changed the API:
> http://mupuf.org/blog/2014/05/14/introducing-sandbox-utils-0-6-1/
>
> I really wish we can have everyone onboard on one solution to get these
> cross-platform apps and so far, I do not see any better solution than WSM.
>
> Martin
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

Thanks for the links! I'll read through them. I figured that a
discussion like this had happened in the past around how to give clients
privledge, but I couldn't find anything that would allow them to
actually do the thing they were given permission to. We should flesh out
both parts of this model. I read over libwsm and it seems like a fairly
sane approach. I'd like to read the arguments for/against it.

> This approach has generally be liked by KDE, but not by Gnome who, last i
> heard, did not care about cross-platform apps doing privileged operations.
> This may have changed since they also decided to work on sandboxing
> (xdg-app) and implemented something like the following approach when they
> said they would never do because it changed the API:
> http://mupuf.org/blog/2014/05/14/introducing-sandbox-utils-0-6-1/

I would hope that our friends at Gnome aren't planning on implementing
software to cover every screen capturing use case in mutter! I'd like to
find a way to use OBS (https://obsproject.com/) from Wayland, for
example.

> I really wish we can have everyone onboard on one solution to get these
> cross-platform apps and so far, I do not see any better solution than WSM.

Well, I'm definitely on board. Sway is clearly a smaller project than
Gnome or KDE and I would rather not build the "Sway Desktop
Environment". I think we can arrive at some solutions that are in line
with the Unix way AND meet the goals of the big DEs.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Collaboration on standard Wayland protocol extensions

[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), and I have
reached out to each of the projects this message is addressed to (GNOME,
Kwin, and wayland-devel) to collaborate on some shared protocol
extensions for doing a handful of common tasks such as display
configuration and taking screenshots. Life will be much easier for
projects like ffmpeg and imagemagick if they don't have to implement
compositor-specific code for capturing the screen!

I want to start by establishing the requirements for these protocols.
Broadly speaking, I am looking to create protocols for the following
use-cases:

- Screen capture
- Output configuration
- More detailed surface roles (should it be floating, is it a modal,
  does it want to draw its own decorations, etc)
- Input device configuration

I think that these are the core protocols necessary for
cross-compositor compatability and to support most existing tools for
X11 like ffmpeg. Considering the security goals of Wayland, it will also
likely be necessary to implement some kind of protocol for requesting
and granting sensitive permissions to clients.

How does this list look? What sorts of concerns do you guys have with
respect to what features each protocol needs to support? Have I missed
any major protocols that we'll have to work on? Once we have a good list
of requirements I'll start writing some XML.

--
Drew DeVault
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list