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-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote:
> On 2016-03-29 10:30 AM, Jonas Ådahl wrote:
> > I'm just going to put down my own personal thoughts on these. I mostly
> > agree with Carsten on all of this. In general, my opinion is that it is
> > completely pointless to add Wayland protocols for things that has
> > nothing to do with Wayland what so ever; we have other display protocol
> > agnostic methods for that that fits much better.
> 
> I think these features have a lot to do with Wayland, and I still
> maintain that protocol extensions make sense as a way of doing it. I
> don't want to commit my users to dbus or something similar and I'd
> prefer if I didn't have to make something unique to sway. It's probably
> going to be protocol extensions for some of this stuff and I think it'd
> be very useful for the same flexibility to be offered by other
> compositors.
> 
> > As a rule of thumb, whether a feature needs a Wayland protocol or not,
> > one can consider whether a client needs to reference a client side
> > object (such as a surface) on the server. If it needs it, we should add
> > a Wayland protocol; otherwise not. Another way of seeing it would be
> > "could this be shared between Wayland/X11/Mir/... then don't do it in
> > any of those".
> 
> I prefer to think of it as "who has logical ownership over this resource
> that they're providing". The compositor has ownership of your output and
> input devices and so on, and it should be responsible for making them
> available.

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

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

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

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

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-29 11:31 AM, Carsten Haitzler wrote:
> my take on it is that it's premature and not needed at this point. in fact i
> wouldn't implement a protocol at all. *IF* i were to allow special access, i'd
> simply require to fork the process directly from compositor and provide a
> socketpair fd to this process and THAT fd could have extra capabilities
> attached to the wl protocol. i would do nothing else because as a compositor i
> cannot be sure what i am executing. i'd hand over the choice of being able to
> execute this tool to the user to say ok to and not just blindly execute
> anything i like.

I don't really understand why forking from the compositor and bringing
along the fds really gives you much of a gain in terms of security. Can
you elaborate on how this changes things? I should also mention that I
don't really see the sort of security goals Wayland has in mind as
attainable until we start doing things like containerizing applications,
in which case we can elimitate entire classes of problems from this
design.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-29 10:30 AM, Jonas Ådahl wrote:
> I'm just going to put down my own personal thoughts on these. I mostly
> agree with Carsten on all of this. In general, my opinion is that it is
> completely pointless to add Wayland protocols for things that has
> nothing to do with Wayland what so ever; we have other display protocol
> agnostic methods for that that fits much better.

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

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

I prefer to think of it as "who has logical ownership over this resource
that they're providing". The compositor has ownership of your output and
input devices and so on, and it should be responsible for making them
available.

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

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

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

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

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

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

This sounds reasonable.

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[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

[Jonas Ådahl]

On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote:
> Greetings! I am the maintainer of the Sway Wayland compositor.
> 
> http://swaywm.org
> 
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:

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

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

> 
> - Screen capture

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

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

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

> - Output configuration

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

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

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

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

> - Input device configuration

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

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

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

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


Jonas

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

Re: [PATCH weston v2 03/10] compositor: Track surface activity

[Bryce Harrington]

On Mon, Mar 28, 2016 at 10:25:24AM +0300, Giulio Camuffo wrote:
> 2016-03-24 20:27 GMT+02:00 Bryce Harrington :
> > Surfaces flagged as 'active' are considered of primary urgency to the
> > user.  It might be the surface with the keyboard focus or displaying
> > something important; the exact specification of what 'active' means is
> > left as shell-specific.
> >
> > An 'active' surface may be granted special treatment by the compositor.
> > For instance, it may only honor inhibition requests by active surfaces.
> >
> > Signed-off-by: Bryce Harrington 
> > ---
> >  src/compositor.c | 41 +
> >  src/compositor.h | 20 +---
> >  src/input.c  | 15 ---
> >  3 files changed, 58 insertions(+), 18 deletions(-)
> >
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 4b091b0..574a0b8 100644
> > --- a/src/compositor.c
> > +++ b/src/compositor.c
> > @@ -612,6 +612,7 @@ weston_surface_create(struct weston_compositor 
> > *compositor)
> > weston_matrix_init(>buffer_to_surface_matrix);
> > weston_matrix_init(>surface_to_buffer_matrix);
> >
> > +   surface->active = false;
> > surface->inhibit_screensaving = false;
> >
> > return surface;
> > @@ -3424,6 +3425,46 @@ weston_surface_copy_content(struct weston_surface 
> > *surface,
> >  src_x, src_y, width, height);
> >  }
> >
> > +/** Set surface as active.
> > + *
> > + *  Marks a surface as considered 'active' by the shell
> > + *  and gives the surface keyboard focus.
> > + */
> > +WL_EXPORT void
> > +weston_surface_activate(struct weston_surface *surface,
> > +struct weston_seat *seat)
> 
> weston_surface_activate was previously only setting the keyboard
> focus, even though the name of the function was maybe ill chosen. Now
> you're giving it another meaning, that is it sets the 'active' state
> of the surface (as the name of the function suggests) but you're
> keeping the old meaning too.

Yeah, I know, it seems a bit awkward to me too.

> I would split them apart, a shell may
> want to e.g. set also the pointer focus surface as active, while
> keeping the keyboard focus where it is.

I was tempted to do this too, but wasn't sure if that might be too
invasive of a change?

Thanks for the review,
Bryce

> Cheers,
> Giulio
> 
> > +{
> > +struct weston_compositor *compositor = seat->compositor;
> > +struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
> > +
> > +   surface->active = true;
> > +
> > +if (keyboard) {
> > +weston_keyboard_set_focus(keyboard, surface);
> > +wl_data_device_set_keyboard_focus(seat);
> > +}
> > +
> > +wl_signal_emit(>activate_signal, surface);
> > +}
> > +
> > +/** Set surface as inactive.
> > + *
> > + *  Marks a surface as no longer considered 'active' by the shell.
> > + *  Note that this does not change keyboard focus.
> > + */
> > +WL_EXPORT void
> > +weston_surface_deactivate(struct weston_surface *surface,
> > +  struct weston_seat *seat)
> > +{
> > +   surface->active = false;
> > +}
> > +
> > +WL_EXPORT bool
> > +weston_surface_is_active(struct weston_surface *surface)
> > +{
> > +   return surface->active;
> > +}
> > +
> >  static void
> >  subsurface_set_position(struct wl_client *client,
> > struct wl_resource *resource, int32_t x, int32_t y)
> > diff --git a/src/compositor.h b/src/compositor.h
> > index d982feb..9a9ab1a 100644
> > --- a/src/compositor.h
> > +++ b/src/compositor.h
> > @@ -1039,11 +1039,19 @@ struct weston_surface {
> > struct weston_timeline_object timeline;
> >
> > /*
> > +* A shell-specific indicator that the surface is in immediate
> > +* use by the user.  For example, the surface might have keyboard
> > +* focus.
> > +*/
> > +   bool active;
> > +
> > +   /*
> >  * Indicates the surface prefers no screenblanking, screensaving,
> >  * or other automatic obscurement to kick in while the surface is
> >  * considered "active" by the shell.
> >  */
> > bool inhibit_screensaving;
> > +
> >  };
> >
> >  struct weston_subsurface {
> > @@ -1129,9 +1137,6 @@ int
> >  weston_spring_done(struct weston_spring *spring);
> >
> >  void
> > -weston_surface_activate(struct weston_surface *surface,
> > -   struct weston_seat *seat);
> > -void
> >  notify_motion(struct weston_seat *seat, uint32_t time,
> >   struct weston_pointer_motion_event *event);
> >  void
> > @@ -1409,6 +1414,15 @@ weston_surface_copy_content(struct weston_surface 
> > *surface,
> > int src_x, int src_y,
> > int width, int height);
> >
> > +void
> > +weston_surface_activate(struct weston_surface *surface,
> > + 

Re: [PATCH v2 wayland-web] Updated build instructions for wayland-protocols and libwacom

[Peter Hutterer]

On Fri, Mar 25, 2016 at 07:37:33PM -0700, spit...@gmail.com wrote:
> From: Bill Spitzak 
> 
> The Mint instructions have been tested, I had to guess at the Ubuntu12
> instructions as I no longer have that machine.
> 
> v2: Use MAKEFLAGS instead of switches
> Use  instead of &
> Some rewording of Ubuntu instructions to point out they are old
> 
> Signed-off-by: Bill Spitzak 

looks correct, but I only skimmed it. One comment, most unrelated: I prefer
to use pushd/popd over cd .. and the like, it makes copy-pasting a lot safer
and more reliable to dtrt in case of errors.

Cheers,
   Peter

> ---
>  building.html|  2 ++
>  mint17.html  | 58 
> 
>  ubuntu12.04.html | 31 ++
>  3 files changed, 58 insertions(+), 33 deletions(-)
> 
> diff --git a/building.html b/building.html
> index 7bfcd8b..b5a83dc 100644
> --- a/building.html
> +++ b/building.html
> @@ -238,6 +238,8 @@ $ cd ..
>http://www.freedesktop.org/wiki/Software/libevdev/;>libevdev,
>this is in  href="http://cgit.freedesktop.org/libevdev;>git://anongit.freedesktop.org/libevdev
>  
> +https://sourceforge.net/projects/linuxwacom/;>libwacom 
> source is in git://git.code.sf.net/p/linuxwacom/libwacom
> +
>  http://xkbcommon.org/;>libxkbcommon source is
>  in  href="http://github.com/xkbcommon/libxkbcommon;>git://github.com/xkbcommon/libxkbcommon.
>  
> diff --git a/mint17.html b/mint17.html
> index ae1c5a8..a1f8341 100644
> --- a/mint17.html
> +++ b/mint17.html
> @@ -12,7 +12,7 @@
>  Building Weston on Linux Mint 17
>  
>  The following sequence of commands successfully built Weston and
> -XWayland on a Linux Mint 17 Cinnamon system, on October 28 2014. These
> +XWayland on a Linux Mint 17.3 Cinnamon system, on March 2, 2016. These
>  commands will probably work on any system based on Ubuntu 14.04.
>  
>  This is considerably easier than earlier systems as the distributed
> @@ -29,26 +29,42 @@ export PATH=$WLD/bin:$PATH
>  export ACLOCAL_PATH=$WLD/share/aclocal
>  export ACLOCAL="aclocal -I $ACLOCAL_PATH"
>  mkdir -p $ACLOCAL_PATH
> +export MAKEFLAGS="j9" # or use your own flags
>  
>  # libwayland:
>  
> -apt install libffi-dev libexpat-dev
> +apt install libffi-dev libexpat-dev libxml2-dev
>  apt install doxygen xmlto # or use 
> --disable-documentation
>  
>  git clone git://anongit.freedesktop.org/wayland/wayland
>  cd wayland
>  ./autogen.sh --prefix=$WLD
> -make -j 9 && make install
> +make  make install
> +cd ..
> +
> +# wayland-protocols:
> +
> +git clone git://anongit.freedesktop.org/wayland/wayland-protocols
> +cd wayland-protocols
> +./autogen.sh --prefix=$WLD
> +make  make install
>  cd ..
>  
>  # libinput:
>  
>  apt install libmtdev-dev libudev-dev libevdev-dev
>  
> +# newer version of libwacom is needed than in 
> apt
> +apt install libgudev-1.0-dev
> +git clone git://git.code.sf.net/p/linuxwacom/libwacom
> +cd libwacom
> +make  make install
> +cd ..
> +
>  git clone git://anongit.freedesktop.org/wayland/libinput
>  cd libinput
>  ./autogen.sh --prefix=$WLD
> -make -j 9 && make install
> +make  make install
>  cd ..
>  
>  # weston:
> @@ -60,7 +76,7 @@ apt install libegl1-mesa-dev libgles2-mesa-dev 
> libxcursor-dev libcairo2-dev \
>  git clone git://anongit.freedesktop.org/wayland/weston
>  cd weston
>  ./autogen.sh --prefix=$WLD --disable-setuid-install
> -make -j 9 && make install
> +make  make install
>  cd ..
>  
>  # X Server:
> @@ -71,91 +87,91 @@ apt install libgl1-mesa-dri-dev libgcrypt11-dev 
> libxkbfile-dev libxfont-dev \
>  git clone git://anongit.freedesktop.org/xorg/util/macros
>  cd macros
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/xcmiscproto
>  cd xcmiscproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/lib/libxtrans
>  cd libxtrans
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/bigreqsproto
>  cd bigreqsproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/xproto
>  cd xproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/randrproto
>  cd randrproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/fontsproto
>  cd fontsproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone git://anongit.freedesktop.org/xorg/proto/videoproto
>  cd videoproto
>  ./autogen.sh --prefix=$WLD
> -make && make install
> +make  make install
>  cd ..
>  
>  git clone 

Re: Collaboration on standard Wayland protocol extensions

[Peter Hutterer]

On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote:
> Greetings! I am the maintainer of the Sway Wayland compositor.
> 
> http://swaywm.org
> 
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration

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

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

Cheers,
   Peter

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

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.

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

Re: [libinput] How I get to scroll.wheel_click_angle value using libinput?

[Peter Hutterer]

Hi,

sorry for the delay, only just came back from holidays.

On Thu, Mar 24, 2016 at 02:53:41PM +0900, �� wrote:
> Hello, guys.
> 
> When I check mouse wheel events using libinput,
> I found that this wheel value was always converted by libinput.
> Like this: wheel_degrees.y = -1 * e->value * device-
> >scroll.wheel_click_angle.
> In function evdev_process_relative().
> 
> That value is set using udev property named "MOUSE_WHEEL_CLICK_ANGLE".
> But if that value is not exist, set default
> value(DEFAULT_WHEEL_CLICK_ANGLE).
> 
> In that case, I move wheel to just one, kernel send wheel event that value
> is 1,
> and libinput changed it to 15(this is currently default value).
> 
> This is my concerned point. I just want to know mouse wheel's real move,
> not converted value.
> So I found how to get that value(scroll.wheel_click_angle) for revert value
> to 1(like via kernel)
> But currently libinput_device_config_scroll_* API's doesn't support this.
> 
> How can I get this value?
> Or how about make a new API like
> libinput_device_config_scroll_get_wheel_click_angle()?
> If you this make sense, I will upload a commit to add a new API.

we export the number of clicks already, look for
libinput_event_pointer_get_axis_value_discrete() here:
https://wayland.freedesktop.org/libinput/doc/latest/group__event__pointer.html

Cheers,
   Peter

PS: doxygen grouping was wrong, this API wasn't listed until 5 minutes ago,
sorry.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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.

> 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.

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

I agree, permission management on Firefox is good.

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

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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Martin Peres]

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

On 2016-03-27 10:21 PM, Jasper St. Pierre wrote:

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

Agreed. I think it should be pretty straightforward:

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


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


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


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

This is why we wanted to let distro devs decide for their users what
the default policy should be. We then need to have a good UI for users
to realize that the application is running in fullscreen mode (following
what chrome and firefox are doing is likely a good idea).

However, Jasper has a point that we need to be sure that we can
override the policy in a consistent way across all backends. I have a
plan for this.

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

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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Introduction and updates from NVIDIA

[Daniel Vetter]

On Thu, Mar 24, 2016 at 10:06:04AM -0700, Andy Ritger wrote:
> On Wed, Mar 23, 2016 at 11:48:01AM +0100, Daniel Vetter wrote:
> > On Tue, Mar 22, 2016 at 05:33:57PM -0700, Andy Ritger wrote:
> > > On Tue, Mar 22, 2016 at 09:52:21PM +, Daniel Stone wrote:
> > > > Hi,
> > > > 
> > > > On 22 March 2016 at 21:43, Daniel Vetter  wrote:
> > > > > On Tue, Mar 22, 2016 at 01:49:59PM +, Daniel Stone wrote:
> > > [...]
> > > > >> I think it's been good to have this series to push the discussion
> > > > >> further in more concrete terms, but unfortunately I have to say that
> > > > >> I'm even less convinced now than I have ever been. Sorry.
> > > > >
> > > > > Well the thing that irks me is that this isn't aiming to build a 
> > > > > common
> > > > > platform. There's definitely issues with gbm/gralloc+kms+egl in 
> > > > > upstream
> > > > > repos, and vendors have hacked around those in all kinds of horrible 
> > > > > ways.
> > > > > But trying to fix this mess with yet another vendor-private solution 
> > > > > just
> > > > > doesn't help. Instead we need to fix what is there, for everyone, 
> > > > > instead
> > > > > of fragmenting more.
> > > > 
> > > > Agreed. One of the things I've been incredibly happy with is how our
> > > > platform has managed to stay completely generic and vendor-neutral so
> > > > far, and I'd love to preserve that.
> > > 
> > > I don't think you'll find any disagreement to that from NVIDIA, either.
> > > 
> > > I apologize if the EGLStreams proposal gave the impression of a
> > > vendor-private solution.  That wasn't the intent.  The EGLStream family
> > > of extensions are, after all, an open specification that any EGL vendor
> > > can implement.  If there are aspects of any of these EGL extensions that
> > > seem useful, I'd hope that Mesa would we willing to adopt them.
> > > 
> > > We (NVIDIA) clearly think EGLStreams is a good direction for expressing
> > > buffer sharing semantics.  In our ideal world, everyone would implement
> > > these extensions and Wayland compositors would migrate to using them as
> > > the generic vendor-neutral mechanism for buffer sharing :)
> > > 
> > > But, I'm also happy discuss ways to incrementally improve gbm.  I tried
> > > to address Daniel (Stone)'s questions about NVIDIA's gbm concerns.  For 
> > > this:
> > 
> > So I guess the top level issue with eglstreams+kms that at least I see is
> > that if we really want to do this, we would need to terminate the
> > eglstream in the kernel. Since with kms really only the kernel knows why
> > exactly a buffer isn't the right one, and what the producer should change
> > to get to a more optimal setup.
> >
> > But the problem is that KMS is ABI and vendor-neutral, which means all
> > that fancy metadata that you want to attach would need to be standardized
> > in some way. And we'd need to have in-kernel eglstreams. So you'd face
> > both the problem of getting a new primitive into upstream (dma-buf took
> > massive efforts, same for fences going on now). And you'd lose the benefit
> > of eglstreams being able to encapsulate vendor metadata.
> > 
> > And we need to figure out how to standardize this a bit better even
> > without eglstreams, so that's why I don't really understand why eglstreams
> > has benefits. It's clearly a nice concept if your in a world of
> > one-vendor-only, but that's not what KMS is aiming for really.
> 
> eglstreams or gbm or any other implementation aside, is it always _only_
> the KMS driver that knows what the optimal configuration would be?
> It seems like part of the decision could require knowledge of the graphics
> hardware, which presumably the OpenGL/EGL driver is best positioned
> to have.

Android agrees with that and stuffs all these decisions into hwc. And I
agree that there's cases with combinations of display block, 2d engined
and 3d engine where that full-system overview is definitely necessary. But
OpenGL still doesn't look like the right place to me. Something in-between
everything else, like hwc+gralloc on android (which has its own issues)
makes a lot more sense imo in a world where you can combine things widly.

I do believe though that with just kms + sensible heuristics to allocate
surfaces to hw planes + some semi-clever fallback mechanism/hints (which
is what we currently lack) it should be possible to pull something off
without special-case vendor magic in hwc for every combination. That's
purely a conjecture though on my part, otoh no one has ever really tried
all that hard yet.

> For that aspect: would it be reasonable to execute hardware-specific
> driver code in the drmModeAtomicCommit() call chain between the
> application calling libdrm to make the atomic update, and the ioctl
> into the kernel?  Maybe that would be a call to libgbm that dispatches to
> the hardware-specific gbm backend.  However it is structured, having
> hardware-specific graphics driver code execute as part of the flip
> request might be one way 

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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

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

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

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

man ffmpeg-all

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

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

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

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

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

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

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

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

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

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

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

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

> > primary display? What about 

Re: Collaboration on standard Wayland protocol extensions

[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

[Drew DeVault]

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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

Agreed. I think it should be pretty straightforward:

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

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

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

Re: Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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

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

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

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

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

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

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

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

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

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

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

I currently 

Re: [PATCH weston v4] refactor x11-backend configuration API

[Giulio Camuffo]

Sorry, i hit send by mistake before i was finished...

2016-03-28 11:45 GMT+03:00 Giulio Camuffo :
> 2016-03-21 23:58 GMT+02:00 Benoit Gschwind :
>> Use a "well" defined structure to configure x11-backend and move 
>> configuration
>> file parsing inside the weston compositor code.
>>
>> v4: add struct_version, and check for null pointer of the configuration
>> structure.
>> v3: properly check memory error for the memory allocation of the outputs
>> array.
>> v2: add struct_size and related change, change output list from wl_list
>> to regular C array.
>> v1: initial implementation.
>> ---
>>  Makefile.am  |   1 +
>>  src/compositor-x11.c | 154 +++---
>>  src/compositor-x11.h |  82 +++
>>  src/compositor.h |   1 +
>>  src/main.c   | 184 
>> ++-
>>  5 files changed, 319 insertions(+), 103 deletions(-)
>>  create mode 100644 src/compositor-x11.h
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 623621d..7acef6a 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -72,6 +72,7 @@ weston_SOURCES =  \
>> src/log.c   \
>> src/compositor.c\
>> src/compositor.h\
>> +   src/compositor-x11.h\
>> src/input.c \
>> src/data-device.c   \
>> src/screenshooter.c \
>> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
>> index 13a5d73..b7eecad 100644
>> --- a/src/compositor-x11.c
>> +++ b/src/compositor-x11.c
>> @@ -50,6 +50,7 @@
>>  #include 
>>
>>  #include "compositor.h"
>> +#include "compositor-x11.h"
>>  #include "gl-renderer.h"
>>  #include "pixman-renderer.h"
>>  #include "shared/config-parser.h"
>> @@ -60,11 +61,6 @@
>>
>>  #define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
>>
>> -static int option_width;
>> -static int option_height;
>> -static int option_scale;
>> -static int option_count;
>> -
>>  struct x11_backend {
>> struct weston_backendbase;
>> struct weston_compositor *compositor;
>> @@ -105,6 +101,7 @@ struct x11_backend {
>> xcb_atom_t   cardinal;
>> xcb_atom_t   xkb_names;
>> } atom;
>> +
>
> Try to avoid this newline changes, there are a few of them in the patch.
>
>>  };
>>
>>  struct x11_output {
>> @@ -130,6 +127,11 @@ struct window_delete_data {
>>
>>  struct gl_renderer_interface *gl_renderer;
>>
>> +static void
>> +weston_x11_backend_config_init_default(struct weston_x11_backend_config * 
>> ths) {
>
> Brackets for functions go on a newline.
>
>> +   bzero(ths, sizeof(*ths));
>
> bzero is deprecated.
>
>> +}
>> +
>>  static xcb_screen_t *
>>  x11_compositor_get_default_screen(struct x11_backend *b)
>>  {
>> @@ -1548,6 +1550,7 @@ x11_destroy(struct weston_compositor *ec)
>> weston_compositor_shutdown(ec); /* destroys outputs, too */
>>
>> XCloseDisplay(backend->dpy);
>> +
>> free(backend);
>>  }
>>
>> @@ -1568,23 +1571,24 @@ init_gl_renderer(struct x11_backend *b)
>>  }
>>  static struct x11_backend *
>>  x11_backend_create(struct weston_compositor *compositor,
>> -  int fullscreen,
>> -  int no_input,
>> -  int use_pixman,
>> -  int *argc, char *argv[],
>> -  struct weston_config *config)
>> +  struct weston_x11_backend_config *foreign_config)
>>  {
>> struct x11_backend *b;
>> struct x11_output *output;
>> -   struct weston_config_section *section;
>> -   int i, x = 0, output_count = 0;
>> -   int width, height, scale, count;
>> -   const char *section_name;
>> -   char *name, *t, *mode;
>> -   uint32_t transform;
>> +   struct weston_x11_backend_config config = { 0, };
>> +   int x = 0;
>> +   unsigned i;
>>
>> weston_log("initializing x11 backend\n");
>>
>> +   if(foreign_config == NULL ||
>> +  foreign_config->struct_version != 
>> WESTON_X11_BACKEND_CONFIG_VERSION ||
>> +  foreign_config->struct_size > sizeof(struct 
>> weston_x11_backend_config))
>> +   return NULL;
>> +
>> +   weston_x11_backend_config_init_default();
>
> You already initialized the struct to 0 above, so what's the point of this 
> call?
>
>> +   memcpy(, foreign_config, foreign_config->struct_size);
>> +
>> b = zalloc(sizeof *b);
>> if (b == NULL)
>> return NULL;
>> @@ -1609,13 +1613,13 @@ x11_backend_create(struct weston_compositor 
>> *compositor,
>> x11_backend_get_resources(b);
>> x11_backend_get_wm_info(b);
>>
>> -   if (!b->has_net_wm_state_fullscreen && fullscreen) {
>> +   

Re: [PATCH weston v4] refactor x11-backend configuration API

[Giulio Camuffo]

2016-03-21 23:58 GMT+02:00 Benoit Gschwind :
> Use a "well" defined structure to configure x11-backend and move configuration
> file parsing inside the weston compositor code.
>
> v4: add struct_version, and check for null pointer of the configuration
> structure.
> v3: properly check memory error for the memory allocation of the outputs
> array.
> v2: add struct_size and related change, change output list from wl_list
> to regular C array.
> v1: initial implementation.
> ---
>  Makefile.am  |   1 +
>  src/compositor-x11.c | 154 +++---
>  src/compositor-x11.h |  82 +++
>  src/compositor.h |   1 +
>  src/main.c   | 184 
> ++-
>  5 files changed, 319 insertions(+), 103 deletions(-)
>  create mode 100644 src/compositor-x11.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 623621d..7acef6a 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -72,6 +72,7 @@ weston_SOURCES =  \
> src/log.c   \
> src/compositor.c\
> src/compositor.h\
> +   src/compositor-x11.h\
> src/input.c \
> src/data-device.c   \
> src/screenshooter.c \
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index 13a5d73..b7eecad 100644
> --- a/src/compositor-x11.c
> +++ b/src/compositor-x11.c
> @@ -50,6 +50,7 @@
>  #include 
>
>  #include "compositor.h"
> +#include "compositor-x11.h"
>  #include "gl-renderer.h"
>  #include "pixman-renderer.h"
>  #include "shared/config-parser.h"
> @@ -60,11 +61,6 @@
>
>  #define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
>
> -static int option_width;
> -static int option_height;
> -static int option_scale;
> -static int option_count;
> -
>  struct x11_backend {
> struct weston_backendbase;
> struct weston_compositor *compositor;
> @@ -105,6 +101,7 @@ struct x11_backend {
> xcb_atom_t   cardinal;
> xcb_atom_t   xkb_names;
> } atom;
> +

Try to avoid this newline changes, there are a few of them in the patch.

>  };
>
>  struct x11_output {
> @@ -130,6 +127,11 @@ struct window_delete_data {
>
>  struct gl_renderer_interface *gl_renderer;
>
> +static void
> +weston_x11_backend_config_init_default(struct weston_x11_backend_config * 
> ths) {

Brackets for functions go on a newline.

> +   bzero(ths, sizeof(*ths));

bzero is deprecated.

> +}
> +
>  static xcb_screen_t *
>  x11_compositor_get_default_screen(struct x11_backend *b)
>  {
> @@ -1548,6 +1550,7 @@ x11_destroy(struct weston_compositor *ec)
> weston_compositor_shutdown(ec); /* destroys outputs, too */
>
> XCloseDisplay(backend->dpy);
> +
> free(backend);
>  }
>
> @@ -1568,23 +1571,24 @@ init_gl_renderer(struct x11_backend *b)
>  }
>  static struct x11_backend *
>  x11_backend_create(struct weston_compositor *compositor,
> -  int fullscreen,
> -  int no_input,
> -  int use_pixman,
> -  int *argc, char *argv[],
> -  struct weston_config *config)
> +  struct weston_x11_backend_config *foreign_config)
>  {
> struct x11_backend *b;
> struct x11_output *output;
> -   struct weston_config_section *section;
> -   int i, x = 0, output_count = 0;
> -   int width, height, scale, count;
> -   const char *section_name;
> -   char *name, *t, *mode;
> -   uint32_t transform;
> +   struct weston_x11_backend_config config = { 0, };
> +   int x = 0;
> +   unsigned i;
>
> weston_log("initializing x11 backend\n");
>
> +   if(foreign_config == NULL ||
> +  foreign_config->struct_version != 
> WESTON_X11_BACKEND_CONFIG_VERSION ||
> +  foreign_config->struct_size > sizeof(struct 
> weston_x11_backend_config))
> +   return NULL;
> +
> +   weston_x11_backend_config_init_default();

You already initialized the struct to 0 above, so what's the point of this call?

> +   memcpy(, foreign_config, foreign_config->struct_size);
> +
> b = zalloc(sizeof *b);
> if (b == NULL)
> return NULL;
> @@ -1609,13 +1613,13 @@ x11_backend_create(struct weston_compositor 
> *compositor,
> x11_backend_get_resources(b);
> x11_backend_get_wm_info(b);
>
> -   if (!b->has_net_wm_state_fullscreen && fullscreen) {
> +   if (!b->has_net_wm_state_fullscreen && config.fullscreen) {
> weston_log("Can not fullscreen without window manager support"
>"(need _NET_WM_STATE_FULLSCREEN)\n");
> -   fullscreen = 0;
> +   

Re: [PATCH wayland-protocols v3] Add screensaver idle inhibitor protocol

[Giulio Camuffo]

2016-03-24 20:14 GMT+02:00 Bryce Harrington :
> This interface allows disabling of screensaver/screenblanking on a
> per-surface basis.  As long as the surface remains visible and
> non-occluded it blocks the screensaver, etc. from activating on the
> output(s) that the surface is visible on.
>
> To uninhibit, simply destroy the inhibitor object.
>
> Signed-off-by: Bryce Harrington 
> ---
> v2: Rename protocol to idle-inhibit
>  + Use "idle" rather than "screensaver".  People likely to be interested
>in this protocol would know the difference between "blanking", "dpms",
>and literal "screensavers", so don't lead them to think that this only
>deals with the latter.  The protocol addresses all manner of idle
>behaviors, so is a more accurate name.
>  + Standardize nomenclature to "idle-manager" and "inhibitor" for clarity.
>"inhibition_inhibit" was just too cumbersome.
>
>  Makefile.am|  1 +
>  unstable/idle-inhibit/README   |  4 ++
>  unstable/idle-inhibit/idle-inhibit-unstable-v1.xml | 78 
> ++
>  3 files changed, 83 insertions(+)
>  create mode 100644 unstable/idle-inhibit/README
>  create mode 100644 unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..ac497d8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols =  
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> +   unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  \
> $(NULL)
>
>  nobase_dist_pkgdata_DATA =   
>   \
> diff --git a/unstable/idle-inhibit/README b/unstable/idle-inhibit/README
> new file mode 100644
> index 000..396e871
> --- /dev/null
> +++ b/unstable/idle-inhibit/README
> @@ -0,0 +1,4 @@
> +Screensaver inhibition protocol
> +
> +Maintainers:
> +Bryce Harrington 
> diff --git a/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml 
> b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
> new file mode 100644
> index 000..a8c8a85
> --- /dev/null
> +++ b/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
> @@ -0,1 +1,78 @@
> +
> +
> +
> +  
> +Copyright © 2015-2016 Samsung Electronics Co., Ltd
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  This interface permits inhibiting the idle behavior such as screen
> +  blanking, locking, and screensaving.  The client binds the idle manager
> +  globally, then creates idle-inhibitor objects for each surface.
> +
> +  Warning! The protocol described in this file is experimental and
> +  backward incompatible changes may be made. Backward compatible changes
> +  may be added together with the corresponding interface version bump.
> +  Backward incompatible changes are done by bumping the version number in
> +  the protocol and interface names and resetting the interface version.
> +  Once the protocol is to be declared stable, the 'z' prefix and the
> +  version number in the protocol and interface names are removed and the

Kind ok OT, but reading this made me wonder if it would make sense to
leave the version number in the interface name even when protocols are
stable. Sometimes problems slip through stabilization processes and it
may still be needed to do a backward incompatible change.

> +  interface version number is reset.
> +
> +
> +
> +  
> +   Create a new inhibitor object associated 

Re: [PATCH weston v2 03/10] compositor: Track surface activity

[Giulio Camuffo]

2016-03-24 20:27 GMT+02:00 Bryce Harrington :
> Surfaces flagged as 'active' are considered of primary urgency to the
> user.  It might be the surface with the keyboard focus or displaying
> something important; the exact specification of what 'active' means is
> left as shell-specific.
>
> An 'active' surface may be granted special treatment by the compositor.
> For instance, it may only honor inhibition requests by active surfaces.
>
> Signed-off-by: Bryce Harrington 
> ---
>  src/compositor.c | 41 +
>  src/compositor.h | 20 +---
>  src/input.c  | 15 ---
>  3 files changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 4b091b0..574a0b8 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -612,6 +612,7 @@ weston_surface_create(struct weston_compositor 
> *compositor)
> weston_matrix_init(>buffer_to_surface_matrix);
> weston_matrix_init(>surface_to_buffer_matrix);
>
> +   surface->active = false;
> surface->inhibit_screensaving = false;
>
> return surface;
> @@ -3424,6 +3425,46 @@ weston_surface_copy_content(struct weston_surface 
> *surface,
>  src_x, src_y, width, height);
>  }
>
> +/** Set surface as active.
> + *
> + *  Marks a surface as considered 'active' by the shell
> + *  and gives the surface keyboard focus.
> + */
> +WL_EXPORT void
> +weston_surface_activate(struct weston_surface *surface,
> +struct weston_seat *seat)

weston_surface_activate was previously only setting the keyboard
focus, even though the name of the function was maybe ill chosen. Now
you're giving it another meaning, that is it sets the 'active' state
of the surface (as the name of the function suggests) but you're
keeping the old meaning too. I would split them apart, a shell may
want to e.g. set also the pointer focus surface as active, while
keeping the keyboard focus where it is.


Cheers,
Giulio

> +{
> +struct weston_compositor *compositor = seat->compositor;
> +struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
> +
> +   surface->active = true;
> +
> +if (keyboard) {
> +weston_keyboard_set_focus(keyboard, surface);
> +wl_data_device_set_keyboard_focus(seat);
> +}
> +
> +wl_signal_emit(>activate_signal, surface);
> +}
> +
> +/** Set surface as inactive.
> + *
> + *  Marks a surface as no longer considered 'active' by the shell.
> + *  Note that this does not change keyboard focus.
> + */
> +WL_EXPORT void
> +weston_surface_deactivate(struct weston_surface *surface,
> +  struct weston_seat *seat)
> +{
> +   surface->active = false;
> +}
> +
> +WL_EXPORT bool
> +weston_surface_is_active(struct weston_surface *surface)
> +{
> +   return surface->active;
> +}
> +
>  static void
>  subsurface_set_position(struct wl_client *client,
> struct wl_resource *resource, int32_t x, int32_t y)
> diff --git a/src/compositor.h b/src/compositor.h
> index d982feb..9a9ab1a 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -1039,11 +1039,19 @@ struct weston_surface {
> struct weston_timeline_object timeline;
>
> /*
> +* A shell-specific indicator that the surface is in immediate
> +* use by the user.  For example, the surface might have keyboard
> +* focus.
> +*/
> +   bool active;
> +
> +   /*
>  * Indicates the surface prefers no screenblanking, screensaving,
>  * or other automatic obscurement to kick in while the surface is
>  * considered "active" by the shell.
>  */
> bool inhibit_screensaving;
> +
>  };
>
>  struct weston_subsurface {
> @@ -1129,9 +1137,6 @@ int
>  weston_spring_done(struct weston_spring *spring);
>
>  void
> -weston_surface_activate(struct weston_surface *surface,
> -   struct weston_seat *seat);
> -void
>  notify_motion(struct weston_seat *seat, uint32_t time,
>   struct weston_pointer_motion_event *event);
>  void
> @@ -1409,6 +1414,15 @@ weston_surface_copy_content(struct weston_surface 
> *surface,
> int src_x, int src_y,
> int width, int height);
>
> +void
> +weston_surface_activate(struct weston_surface *surface,
> +   struct weston_seat *seat);
> +void
> +weston_surface_deactivate(struct weston_surface *surface,
> + struct weston_seat *seat);
> +bool
> +weston_surface_is_active(struct weston_surface *surface);
> +
>  struct weston_buffer *
>  weston_buffer_from_resource(struct wl_resource *resource);
>
> diff --git a/src/input.c b/src/input.c
> index a3d982e..6e35105 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -1206,21 +1206,6 @@ 

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-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel