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: GNOME Calendar plans for 3.22

[Georges Basile Stavracas Neto]

I don't know how any of these topics are related to GNOME Calendar.

Please, reply to the appropriate thread instead.

Em ter, 29 de mar de 2016 às 22:49, Alvaro Kuolas 
escreveu:

> I really love Gnome 3, but the most anti-feature It has (from my point of
> view) are:
>
>  - Tracker installed and enabled as default (it should be optional)
>  - Evolution integration with Gnome Desktop (again, this should be
> optional)
>  - Gvfs and Nautilus seems to be under maintained (it is very slow for
> moving large files or many files)
>
> It should be possible to be more modular and have a more light weight
> desktop with extras as optional and not mandatory?
>
> I would gladly start working on these subject if there is no opposition to
> make them "modular" and "optional".
>
>
> On Wed, Mar 23, 2016 at 1:15 PM, Georges Basile Stavracas Neto <
> georges.stavra...@gmail.com> wrote:
>
>> Greetings,
>>
>> as we release GNOME 3.20, it's time to start thinking about 3.22
>> features. Here's what I have in mind:
>>
>> * - Week view*: there was a mail thread about that, and I'm very happy
>> to announce that Week view *will* happen in this release. Students (and
>> I must say, strong ones) applied for working on this feature for
>> GSoC/Outreachy. Mockups are available since last year [1][2][3][4], and the
>> time to make them is now.
>>
>> * - Edit dialog rework*: Allan kindly reviewed the event editor dialog
>> for Calendar, and we have a strong mockup [5] just waiting to be
>> implemented. In fact, this work will add the ability to handle
>> *recurrency* and *alarms*, long missing features.
>>
>> * - Restyled date picker*: this work will probably happen in Gtk+ side,
>> but a reviewed version of the date picker (GtkCalendar widget) is available
>> [5] and many other applications will benefit from this change
>>
>> Suggestions are very welcome.
>>
>> References:
>> [1]
>> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-wip.png
>> [2]
>> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header.png
>> [3]
>> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header-populated.png
>> [4]
>> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header-expanded.png
>> [5]
>> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/calendar-events-dialog-wires.png
>>
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Calendar plans for 3.22

[Alvaro Kuolas]

I really love Gnome 3, but the most anti-feature It has (from my point of
view) are:

 - Tracker installed and enabled as default (it should be optional)
 - Evolution integration with Gnome Desktop (again, this should be optional)
 - Gvfs and Nautilus seems to be under maintained (it is very slow for
moving large files or many files)

It should be possible to be more modular and have a more light weight
desktop with extras as optional and not mandatory?

I would gladly start working on these subject if there is no opposition to
make them "modular" and "optional".


On Wed, Mar 23, 2016 at 1:15 PM, Georges Basile Stavracas Neto <
georges.stavra...@gmail.com> wrote:

> Greetings,
>
> as we release GNOME 3.20, it's time to start thinking about 3.22 features.
> Here's what I have in mind:
>
> * - Week view*: there was a mail thread about that, and I'm very happy to
> announce that Week view *will* happen in this release. Students (and I
> must say, strong ones) applied for working on this feature for
> GSoC/Outreachy. Mockups are available since last year [1][2][3][4], and the
> time to make them is now.
>
> * - Edit dialog rework*: Allan kindly reviewed the event editor dialog
> for Calendar, and we have a strong mockup [5] just waiting to be
> implemented. In fact, this work will add the ability to handle
> *recurrency* and *alarms*, long missing features.
>
> * - Restyled date picker*: this work will probably happen in Gtk+ side,
> but a reviewed version of the date picker (GtkCalendar widget) is available
> [5] and many other applications will benefit from this change
>
> Suggestions are very welcome.
>
> References:
> [1]
> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-wip.png
> [2]
> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header.png
> [3]
> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header-populated.png
> [4]
> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/week-view-header-expanded.png
> [5]
> https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/calendar-events-dialog-wires.png
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: To GSOC mentors

[Jason D. Clinton]

I don't think this is true; you can get a Google Account without a GMail
account here: https://accounts.google.com/signupwithoutgmail?hl=en


On Tue, Mar 8, 2016 at 4:34 AM, Carlos Soriano Sanchez 
wrote:

> Hello again GSOC mentors,
>
> Forgot to mention an important information. The email address need to be a
> @gmail address.
> This is required by Google and we cannot do anything in that regard.
> However you can send us also a second non-gmail address to use for direct
> communication.
>
> Also, could you tell us a IRC nickname where we can contact you?
>
> Thanks and apologies for the inconvenience,
> GSOC admins
> ___
> soc-mentors-list mailing list
> soc-mentors-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/soc-mentors-list
>
___
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

[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: Design & Development

[Olav Vitters]

Accidentally approved this one. Please ignore
-- 
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

[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: gsoc 2016 idea

[Christophe Fergeau]

Hey,

On Sat, Mar 19, 2016 at 07:01:14PM +0400, Artyom Lyan wrote:
> Hi, all. How can i propose new idea for gsoc 2016? And how to contact
> mentor?
> This idea is related to unity panel.

I would recommend getting in touch with people working on the Unity
panel, presenting them your idea, and see with them if that's a good
project for GSoC. However, the Unity panel is not developed by GNOME
people, and I haven't been able to find Ubuntu as a GSoC organization. I
don't know if they have an umbrella organization which could manage
Unity project for them.

Christophe


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

Design & Development

[jeffrey.cox1...@gmail.com]

Hi,

We specialize in providing truly memorable Responsive Website Design, Web
Development and Online Marketing Solutions.

The site we create and build for your business may include any of the
following website design and development services:

Website Maintenance.

Responsive Web Design.

Motion Graphics and Videos.

Creative Services and Branding.

Mobile application development.

E-Commerce and M-Commerce.

Front-end Development (HTML5).

Content Management Systems (CMS).

WordPress, Drupal, Joomla, Magento, CS-Cart etc.

SEO, PPC and SMO (Twitter, Facebook, Linkedin and other social media
marketing).

We have experience in all facets of web development to help our clients
reach their full potential. Develop your business online and get more sales
and leads.

If you have questions, comments, or other feedback related to our services,
please contact us to discuss.

We are looking your quick response.

Best & Regards,

Jeffrey Cox



--

 This message was sent to desktop-devel-list@gnome.org by
jeffrey.cox1...@gmail.com

 To forward this message, please do not use the forward button of your
email application, because this message was made specifically for you only.
Instead use the forward page

in our newsletter system.

 To change your details and to choose which lists to be subscribed to,
visit your personal preferences page


 Or you can opt-out completely

from all future mailings.

 


-- powered by phpList, www.phplist.com --


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

Re: Giving up maintainership of Dictionary and 2048

[Juan Rafael García Blanco]

Hi all,

Is this discussion closed? If you still do not have a maintainer, I would
be glad to come back now that I have more spare time.

Best regards,
Juan.

On Mon, Sep 21, 2015 at 2:57 PM, Emmanuele Bassi  wrote:

> Hi;
>
> On 16 September 2015 at 19:41, Felipe Borges 
> wrote:
> > Hi,
> >
> > I'm sorry to hear that Pranav can't take the maintainership of
> > gnome-dictionary. So I'm stepping in.
> >
> > As Pranav, I have no previously experience patching Dictionary, but
> > I've been involved in some other GNOME projects and I think this is a
> > great opportunity to learn and give back to the community.
> >
> > If you agree, I'd like to maintain gnome-dictionary from now on.
>
> Thanks for stepping up!
>
> I've just released Dictionary 3.18.0, so any discussion on what can be
> done can start from a stable baseline.
>
> Juan did an amazing job in a visual refresh of the Dictionary's UI; I
> know that there are missing bits, here and there, so ensure that the
> UI adheres to the current HIG. A proper review from the design team
> would be a good initial step.
>
> Then there's the long-standing issue of the Dictionary being a DICT
> client, in a world where DICT servers are a rarity. The "plan" for the
> past few years has been to drop the DICT protocol, and start talking
> to Wiktionary via some API.
>
> If we're moving away from the DICT protocol and custom widgetry
> heavily based on that, then we could start thinking about using
> another language that is not C, to improve the "hackability" aspect of
> the Dictionary — but I would definitely not hold a port to a different
> language as a precondition to working on the application itself.
>
> If you need to ask me questions about the current implementation, feel
> free to poke me on IRC; I'll be happy to answer.
>
> 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: [Builder] Developer experience (DX) hackfest 2016

[James]

On Wed, Dec 30, 2015 at 2:36 AM, Christian Hergert  wrote:
> I did contact her yesterday and the answer was jitsi. It seems
> reasonable, but I haven't had a chance to test it out yet.
>
> https://jitsi.org/

FWIW, I just tried this, and it seems to work similarly to ghangouts,
except that you don't need a google account, which seems to make this
even easier.

Eg: https://meet.jit.si/gnomehackers would just work for everyone. You
might have to change some settings if you want to make it private. I
didn't test screen sharing features or any appreciable size of users
connected simultaneously.

Of note, it seems the meet feature was recently relicensed to ALv2 to
make it easier to enable proprietary addons for other developers, but
it's not something I have much information on.

HTH
___
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