[PATCH 0/6] Add weston randr protocol

[Wang, Quanxian]

Thanks Pq and Jason's comment.

Regards

Quanxian Wang

-----Original Message-----
From: Pekka Paalanen [mailto:ppaalanen at gmail.com] 
Sent: Thursday, February 27, 2014 3:08 PM
To: Wang, Quanxian
Cc: Jason Ekstrand; Kristensen, Kristian H; Zhang, Xiong Y; wayland-devel at lists.freedesktop.org
Subject: Re: [PATCH 0/6] Add weston randr protocol

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.
[Wang, Quanxian] Control individual surface mode in full screen status. Make sense.

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