Re: [PATCH 0/6] Add weston randr protocol
Le 27/02/2014 04:27, Quanxian Wang a écrit : These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. Hi Quanxian, I have submitted such functionality one year ago: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007872.html. The scope was smaller (targeting essentially mode resolution) but it was working. At the time there were no real enthusiasm, some people were even against. Perhaps some have changed their mind since. Regards. -- David FORT website: http://www.hardening-consulting.com/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/6] Add weston randr protocol
-Original Message- From: wayland-devel-boun...@lists.freedesktop.org [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Hardening Sent: Thursday, February 27, 2014 5:15 PM To: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/6] Add weston randr protocol Le 27/02/2014 04:27, Quanxian Wang a écrit : These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. Hi Quanxian, I have submitted such functionality one year ago: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007872.html. The scope was smaller (targeting essentially mode resolution) but it was working. At the time there were no real enthusiasm, some people were even against. Perhaps some have changed their mind since. [Wang, Quanxian] Got it, Thanks. Ahaha. Seems we really need the access control mechanism to make it happen. After all, it should be a good tool from my viewpoint. Regards. -- David FORT website: http://www.hardening-consulting.com/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/6] Add weston randr protocol
For comparison, here is the dbus API that gnome-shell is exposing for display configuration under both X and wayland: https://wiki.gnome.org/Initiatives/Wayland/Gaps/DisplayConfig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/6] Add weston randr protocol
These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. For wayland customer, this application could *DYNAMICALLY* do mode setting in command line. For wayland application developer, weston randr protocol provide a external interface to *DYNAMICALLY* do mode setting instead of static configuring weston at the very beginning. Weston protocol wrandr will provide interface to 1) set output mode 2) set output transform 3) move output to relative position 4) provide disconnected output information Currently randr has more functions to be defined and implemented. Some other functions are planned. But at first we need support. If this protocol is accepted, we could have the chance moving on. The advantage is randr architecture have been defined at this commit. New function will be very easy to be added in the protocol. One note: Currently wl_output doesn't provide wl_output_send_name function, I have to implemented it in randr protocol. Actually it will be very easily implemented in wl_output interface. If this commit series is accepted, I will provide the patch to add wl_output_send_name to make issue simply resolved instead of in randr protocol. ' Here are some test cases. 1. weston-randr -q # query all output mode info and disconnected output HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 ... VGA1 1)1280x1024@60 (current) 2)1152x864@60 3)1024x768@60 ... HDMI1 disconnected HDMI2 disconnected DP1 disconnected DP2 disconnected ... 2. weston-randr --output HDMI3 # query HDMI3 output mode info HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 3. weston-randr --output HDMI3 -m 2 # which will set mode as 1920x1200 4. weston-randr --output HDMI3 -R 1 # rotate HDMI3 output 90 degree 5. weston-randr --output HDMI3 -leftof VGA1 # put HDMI3 output leftof VGA1 6. weston-randr --output HDMI3 -rightof VGA1 # put HDMI3 output rightof VGA1 Quanxian Wang (6): Add weston randr protocol Add weston_randr definition and randr_backend intreface Add the detailed implementation of randr protocol Initialize the randr interface in drm backend Add weston-randr application Change the size of Panel and Background after output's is changed clients/Makefile.am | 9 + clients/desktop-shell.c | 60 + clients/window.c| 7 + clients/window.h| 2 + clients/wrandr.c| 642 protocol/Makefile.am| 1 + protocol/randr.xml | 151 src/Makefile.am | 4 + src/compositor-drm.c| 67 + src/compositor.c| 466 +++ src/compositor.h| 14 ++ 11 files changed, 1376 insertions(+), 47 deletions(-) create mode 100644 clients/wrandr.c create mode 100644 protocol/randr.xml -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/6] Add weston randr protocol
Quanxian, I haven't looked through the code line-by-line, but I do have a few general comments. First, please double-check your copyright blocks. One of your files is copyrighted Benjamin Franzke and another is copyrighted Collabora. I don't think that was intended. Second, it doesn't appear that you have any security mechanism for this? I don't think we want arbitrary clients to be allowed to rotate, change mode, and change output layout. While I agree that it would be great to have a tool (possibly even a command-line one) to do these things dynamically, we shouldn't make it a public interface that just anyone can bind to. I'm not saying that some sort of randr interface isn't needed. I'm simply that it should be privileged and we need a well-defined mechanism for keeping rogue applications from messing up the compositor for everyone else. For standard applications, I believe the intention is that any modesetting they do will be done in a very controlled manner through the shell. Thanks, --Jason Ekstrand On Wed, Feb 26, 2014 at 9:27 PM, Quanxian Wang quanxian.w...@intel.comwrote: These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. For wayland customer, this application could *DYNAMICALLY* do mode setting in command line. For wayland application developer, weston randr protocol provide a external interface to *DYNAMICALLY* do mode setting instead of static configuring weston at the very beginning. Weston protocol wrandr will provide interface to 1) set output mode 2) set output transform 3) move output to relative position 4) provide disconnected output information Currently randr has more functions to be defined and implemented. Some other functions are planned. But at first we need support. If this protocol is accepted, we could have the chance moving on. The advantage is randr architecture have been defined at this commit. New function will be very easy to be added in the protocol. One note: Currently wl_output doesn't provide wl_output_send_name function, I have to implemented it in randr protocol. Actually it will be very easily implemented in wl_output interface. If this commit series is accepted, I will provide the patch to add wl_output_send_name to make issue simply resolved instead of in randr protocol. ' Here are some test cases. 1. weston-randr -q # query all output mode info and disconnected output HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 ... VGA1 1)1280x1024@60 (current) 2)1152x864@60 3)1024x768@60 ... HDMI1 disconnected HDMI2 disconnected DP1 disconnected DP2 disconnected ... 2. weston-randr --output HDMI3 # query HDMI3 output mode info HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 3. weston-randr --output HDMI3 -m 2 # which will set mode as 1920x1200 4. weston-randr --output HDMI3 -R 1 # rotate HDMI3 output 90 degree 5. weston-randr --output HDMI3 -leftof VGA1 # put HDMI3 output leftof VGA1 6. weston-randr --output HDMI3 -rightof VGA1 # put HDMI3 output rightof VGA1 Quanxian Wang (6): Add weston randr protocol Add weston_randr definition and randr_backend intreface Add the detailed implementation of randr protocol Initialize the randr interface in drm backend Add weston-randr application Change the size of Panel and Background after output's is changed clients/Makefile.am | 9 + clients/desktop-shell.c | 60 + clients/window.c| 7 + clients/window.h| 2 + clients/wrandr.c| 642 protocol/Makefile.am| 1 + protocol/randr.xml | 151 src/Makefile.am | 4 + src/compositor-drm.c| 67 + src/compositor.c| 466 +++ src/compositor.h| 14 ++ 11 files changed, 1376 insertions(+), 47 deletions(-) create mode 100644 clients/wrandr.c create mode 100644 protocol/randr.xml -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/6] Add weston randr protocol
From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Thursday, February 27, 2014 11:29 AM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 0/6] Add weston randr protocol Quanxian, I haven't looked through the code line-by-line, but I do have a few general comments. First, please double-check your copyright blocks. One of your files is copyrighted Benjamin Franzke and another is copyrighted Collabora. I don't think that was intended. [Wang, Quanxian] Aha, Sorry about that. I will update that. Some header are copied from others file. I will check that. Thanks for your reminder. Second, it doesn't appear that you have any security mechanism for this? I don't think we want arbitrary clients to be allowed to rotate, change mode, and change output layout. [Wang, Quanxian] The interface's security is not controlled by protocol. As a whole, I think if weston want to control that, it should have an independent security to control that or use the system control. For example, if you want to open the server display from client, we should add the permission denied for that. While I agree that it would be great to have a tool (possibly even a command-line one) to do these things dynamically, we shouldn't make it a public interface that just anyone can bind to. I'm not saying that some sort of randr interface isn't needed. I'm simply that it should be privileged and we need a well-defined mechanism for keeping rogue applications from messing up the compositor for everyone else. For standard applications, I believe the intention is that any modesetting they do will be done in a very controlled manner through the shell. [Wang, Quanxian] Is there any plan for wayland/weston developer to add the security plan to control access? If there is some plan or interface, I can add it in the patches. Currently wayland/weston don't provide a dynamic mode setting. It limited the dynamic action of applications above wayland/weston level. You know, we have to define it in weston config at the very beginning. Do you know anyone or program provide security control in weston code? The objective of this patches provides a way how to do dynamic mode setting. It is really missed in wayland/weston. Thanks, --Jason Ekstrand On Wed, Feb 26, 2014 at 9:27 PM, Quanxian Wang quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote: These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. For wayland customer, this application could *DYNAMICALLY* do mode setting in command line. For wayland application developer, weston randr protocol provide a external interface to *DYNAMICALLY* do mode setting instead of static configuring weston at the very beginning. Weston protocol wrandr will provide interface to 1) set output mode 2) set output transform 3) move output to relative position 4) provide disconnected output information Currently randr has more functions to be defined and implemented. Some other functions are planned. But at first we need support. If this protocol is accepted, we could have the chance moving on. The advantage is randr architecture have been defined at this commit. New function will be very easy to be added in the protocol. One note: Currently wl_output doesn't provide wl_output_send_name function, I have to implemented it in randr protocol. Actually it will be very easily implemented in wl_output interface. If this commit series is accepted, I will provide the patch to add wl_output_send_name to make issue simply resolved instead of in randr protocol. ' Here are some test cases. 1. weston-randr -q # query all output mode info and disconnected output HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 ... VGA1 1)1280x1024@60 (current) 2)1152x864@60 3)1024x768@60 ... HDMI1 disconnected HDMI2 disconnected DP1 disconnected DP2 disconnected ... 2. weston-randr --output HDMI3 # query HDMI3 output mode info HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 3. weston-randr --output HDMI3 -m 2 # which will set mode as 1920x1200 4. weston-randr --output HDMI3 -R 1 # rotate HDMI3 output 90 degree 5. weston-randr --output HDMI3 -leftof VGA1 # put HDMI3 output leftof VGA1 6. weston-randr --output HDMI3 -rightof VGA1 # put HDMI3 output rightof VGA1 Quanxian Wang (6): Add weston randr protocol Add weston_randr definition and randr_backend intreface Add the detailed implementation of randr protocol Initialize the randr interface in drm backend Add weston-randr application Change the size
RE: [PATCH 0/6] Add weston randr protocol
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. 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. 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?) 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. 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. Thanks Regards Quanxian Wang From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Thursday, February 27, 2014 11:29 AM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 0/6] Add weston randr protocol Quanxian, I haven't looked through the code line-by-line, but I do have a few general comments. First, please double-check your copyright blocks. One of your files is copyrighted Benjamin Franzke and another is copyrighted Collabora. I don't think that was intended. Second, it doesn't appear that you have any security mechanism for this? I don't think we want arbitrary clients to be allowed to rotate, change mode, and change output layout. While I agree that it would be great to have a tool (possibly even a command-line one) to do these things dynamically, we shouldn't make it a public interface that just anyone can bind to. I'm not saying that some sort of randr interface isn't needed. I'm simply that it should be privileged and we need a well-defined mechanism for keeping rogue applications from messing up the compositor for everyone else. For standard applications, I believe the intention is that any modesetting they do will be done in a very controlled manner through the shell. Thanks, --Jason Ekstrand On Wed, Feb 26, 2014 at 9:27 PM, Quanxian Wang quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote: These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. For wayland customer, this application could *DYNAMICALLY* do mode setting in command line. For wayland application developer, weston randr protocol provide a external interface to *DYNAMICALLY* do mode setting instead of static configuring weston at the very beginning. Weston protocol wrandr will provide interface to 1) set output mode 2) set output transform 3) move output to relative position 4) provide disconnected output information Currently randr has more functions to be defined and implemented. Some other functions are planned. But at first we need support. If this protocol is accepted, we could have the chance moving on. The advantage is randr architecture have been defined at this commit. New function will be very easy to be added in the protocol. One note: Currently wl_output doesn't provide wl_output_send_name function, I have to implemented it in randr protocol. Actually it will be very easily implemented in wl_output interface. If this commit series is accepted, I will provide the patch to add wl_output_send_name to make issue simply resolved instead of in randr protocol. ' Here are some test cases. 1. weston-randr -q # query all output mode info and disconnected output HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 ... VGA1 1)1280x1024@60 (current) 2)1152x864@60 3)1024x768@60 ... HDMI1 disconnected HDMI2 disconnected DP1 disconnected DP2 disconnected ... 2. weston-randr --output HDMI3 # query HDMI3 output mode info HDMI3 1)1440x900@60 (current) 2)1920x1200@60 3)1680x1050@60 3. weston-randr --output HDMI3 -m 2 # which will set mode as 1920x1200 4. weston-randr --output HDMI3 -R 1 # rotate HDMI3 output 90 degree 5. weston-randr --output HDMI3 -leftof VGA1 # put HDMI3 output leftof VGA1 6. weston-randr --output HDMI3 -rightof VGA1 # put HDMI3 output rightof VGA1 Quanxian Wang (6): Add weston randr protocol
Re: [PATCH 0/6] Add weston randr protocol
On Thu, 27 Feb 2014 05:30:21 + Wang, Quanxian quanxian.w...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/6] Add weston randr protocol
Thanks Pq and Jason's comment. Regards Quanxian Wang -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 3:08 PM To: Wang, Quanxian Cc: Jason Ekstrand; Kristensen, Kristian H; Zhang, Xiong Y; wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/6] Add weston randr protocol On Thu, 27 Feb 2014 05:30:21 + Wang, Quanxian quanxian.w...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
