[PATCH 0/6] Add weston randr protocol

[Pekka Paalanen]

On Thu, 27 Feb 2014 05:30:21 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> Hi, All
> 
> From Jason's comment, about the security issue, I am not sure if I should think about that in this protocol. For communication protocol between client and server, it is hard to control the permission by single protocol. It is not the same as directly call process that we can easily control the user id/group permission. Actually I am a little confused by that. :( Sorry  about that.
> 

Then just simply do not advertise the global interface for this on
usual desktop compositors. Advertise it only on special compositors
where you control what clients can run to begin with. That would be the
first step, and perhaps go nicely with your use case at Tizen IVI.

> If you have some good idea of security process, it will be helpful for me to make some changes.
> 
> Another,
> from my experience on Tizen IVI, I don't find a way to do mode setting from client. It is really missed.

This is completely deliberate. We do NOT want all clients that can
connect to the server to be able to force the video mode at will.

> Whatever for EFL or other application or other libraries which use
 wayland, dynamic mode setting should be one important matrix. But
 until now, no interface or tools provides that. (provided in wayland
 protocol or library?)
> 

We have a shell mechanism for cooperative dynamic, temporary video
mode changes. See wl_shell_surface.set_fullscreen. That request allows
video mode setting in a user-friendly way. By user-friendly I mean in a
way, that e.g. a crashing game cannot leave your display messed up.
Also, a temporary video mode change will not change the size of
your desktop, which means that e.g. if you have icons on the desktop,
they won't get squashed in the top-left corner, and your windows will
stay put. That is what I as a user would expect, when I run a program
that changes the video mode for its running duration, like a game.

Yes, the use cases between a temporary change and the permanent change
done by your proposal are very different. I just want to point out, that
we already have *dynamic* video mode changing for applications.

What you propose is essentially a system configuration & management
interface. Therefore it should be privileged, to avoid abuse.

> The patches provide a way or idea for you to think about that. Maybe I miss something, but I just show my think for that.
> 
> Whatever randr protocol or others protocol, at least it should provide a public interface for user to mode setting.

No, I disagree. It should not be public on desktop compositors.

> By the way, I am not messing up compositor. It is the place I found to put code there. At least it should be in display server level.
> 

You could make it a plugin, which you load only in your special cases,
where clients need to be in control of the video mode explicitly. That
would probably be enough of security until there is a real solution to
granting access to privileged interfaces.

To recap: my only fundamental objection here is about who is allowed to
access this interface, and maybe what its purpose is.


Thanks,
pq