RE: [PATCH 1/6] Add weston randr protocol
Hi, All With the first version of randr protol, I got many useful idea and comments. Thanks. Before I send the email, I have make it happen in real world but need more deep testing. Here are new changes and idea for that protocol based on the idea and comments, welcome your input. 1) Unique operation issue Given that one client has two more threads to do mode setting on the same output at the same time, how to identify what response (done event) is belong to one or another request when they want to get response? This is a design flaw in the first version of randr protocol. The solution is to use the wayland/weston mechanism, every request will generate a resource which be used to send done event to the owner who start it. Owner could set the listener on that and keep tuning on the response event. For example In client: randr_transform = wl_randr_set_transform(randr.randr,wayland_output,argument.transform); /* Here will will add listen callback to get the response for this unique request */ wl_randr_add_listener(randr_transform, randr_transform_listener, randr); In compositor: randr_resource = wl_resource_create(client,wl_randr_interface,1, action); wl_randr_send_action_done(randr_resource, 1WL_RANDR_ACTION_TRANSFORM, ret, action); wl_resource_destroy(randr_resource); 2) Security and mess up issue Will take randr protocol implementation as a module or plugin. This will keep compositor clear and avoid messing up in compositor.c. Also it is will be fine for compositor when this could be public. The security should be a general issue for wayland instead of for randr protocol only. Take randr protocol as a module for user to determine if they want to public randr interface for their clients. Once security mechanism is built up in wayland, randr could adopt the mechanism to enhance the security of randr protocol. weston --tty=1 --modules=wrandr.so or set it in weston.ini like that [core] modules=wrandr.so 3) Group randr operations After talking with PQ, in order to avoid glitches, group operation is needed. However, if operate on two outputs more at one time, it will bring more issues which could not control. In this randr design, will not provide group operation on multiple outputs. We provide atomic operation on one output, multi outputs operation logic are left to designer/developers. Group operation on one output will be designed. For example, you can set mode, scale, and transform at one time with one randr request. 4) Configuration interface Weston randr protocol will be taken as configuration interface for output mode setting in wayland. So the permission for that will be strictly under the control. Before security mechanism is ready, randr module will be designed for compositor as a choice. It is just a loadable module or plugin for special compositors. User will take the decision if start it when boot up compositor as a module. 5) mode setting parameters control Mode and output will be under the control. User could not randomly to set their mode. They have to select the available modes and outputs provided by compositor. Don't allow random mode setting. The mode and output information could be provided by weston-randr apps or wl_output interface. 6) Disconnected outputs When user query output information, showing connected and disconnected output as a whole will be fine for user and QA people. Sometime, QA people or user like that information. It will be helpful for them to identify how many outputs are provided by their machine. Which is connected and which is not connected. 7) wl_output property event Delete get_output_name request and event in protocol. wl_output name event will be added into wl_output protocol. This event will send the output name to user when they bind wl_output. For width and height of wl_output, I am not sure if it is should be sent out at the same time. My idea is it should be the same event to send name, width, height after output is changed. But currently I will not add that. 8) adding set_scale request Mode, scale, transform is the basic property of output, I will add them as a whole. Thanks Regards Quanxian Wang -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 5:45 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 09:15:55 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 4:36 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 08:06:23 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 3:28 PM To: Wang,
Re: [PATCH 1/6] Add weston randr protocol
So, before we go further on this, I need to ask three basic questions: what are the goals of this interface? Who is supposed to use this interface? Why would they use this interface? On Tue, Mar 4, 2014 at 9:07 PM, Wang, Quanxian quanxian.w...@intel.comwrote: Hi, All With the first version of randr protol, I got many useful idea and comments. Thanks. Before I send the email, I have make it happen in real world but need more deep testing. Here are new changes and idea for that protocol based on the idea and comments, welcome your input. 1) Unique operation issue Given that one client has two more threads to do mode setting on the same output at the same time, how to identify what response (done event) is belong to one or another request when they want to get response? This is a design flaw in the first version of randr protocol. The solution is to use the wayland/weston mechanism, every request will generate a resource which be used to send done event to the owner who start it. Owner could set the listener on that and keep tuning on the response event. For example In client: randr_transform = wl_randr_set_transform(randr.randr,wayland_output,argument.transform); /* Here will will add listen callback to get the response for this unique request */ wl_randr_add_listener(randr_transform, randr_transform_listener, randr); In compositor: randr_resource = wl_resource_create(client,wl_randr_interface,1, action); wl_randr_send_action_done(randr_resource, 1WL_RANDR_ACTION_TRANSFORM, ret, action); wl_resource_destroy(randr_resource); 2) Security and mess up issue Will take randr protocol implementation as a module or plugin. This will keep compositor clear and avoid messing up in compositor.c. Also it is will be fine for compositor when this could be public. The security should be a general issue for wayland instead of for randr protocol only. Take randr protocol as a module for user to determine if they want to public randr interface for their clients. Once security mechanism is built up in wayland, randr could adopt the mechanism to enhance the security of randr protocol. weston --tty=1 --modules=wrandr.so or set it in weston.ini like that [core] modules=wrandr.so 3) Group randr operations After talking with PQ, in order to avoid glitches, group operation is needed. However, if operate on two outputs more at one time, it will bring more issues which could not control. In this randr design, will not provide group operation on multiple outputs. We provide atomic operation on one output, multi outputs operation logic are left to designer/developers. Group operation on one output will be designed. For example, you can set mode, scale, and transform at one time with one randr request. 4) Configuration interface Weston randr protocol will be taken as configuration interface for output mode setting in wayland. So the permission for that will be strictly under the control. Before security mechanism is ready, randr module will be designed for compositor as a choice. It is just a loadable module or plugin for special compositors. User will take the decision if start it when boot up compositor as a module. 5) mode setting parameters control Mode and output will be under the control. User could not randomly to set their mode. They have to select the available modes and outputs provided by compositor. Don't allow random mode setting. The mode and output information could be provided by weston-randr apps or wl_output interface. 6) Disconnected outputs When user query output information, showing connected and disconnected output as a whole will be fine for user and QA people. Sometime, QA people or user like that information. It will be helpful for them to identify how many outputs are provided by their machine. Which is connected and which is not connected. 7) wl_output property event Delete get_output_name request and event in protocol. wl_output name event will be added into wl_output protocol. This event will send the output name to user when they bind wl_output. For width and height of wl_output, I am not sure if it is should be sent out at the same time. My idea is it should be the same event to send name, width, height after output is changed. But currently I will not add that. 8) adding set_scale request Mode, scale, transform is the basic property of output, I will add them as a whole. Thanks Regards Quanxian Wang -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 5:45 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 09:15:55 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 4:36 PM To: Wang, Quanxian Cc:
RE: [PATCH 1/6] Add weston randr protocol
From: wayland-devel-boun...@lists.freedesktop.org [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jasper St. Pierre Sent: Wednesday, March 05, 2014 10:53 AM To: Wang, Quanxian Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Pekka Paalanen; Jason Ekstrand; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol So, before we go further on this, I need to ask three basic questions: what are the goals of this interface? Who is supposed to use this interface? Why would they use this interface? [Wang, Quanxian] What are the goals of this interface? The goal of this interface is to provide dynamic mode setting for output. Make wayland desktop configuration more flexible for scale, transform or mode setting. Who is supposed to use this interface? Any customer or user want to rotate, scale or mode the output when they needed. For example, Automotive, there are 2 screens, one is left another is on back, want to rotate the screen. You can sleep, stand, and more body postures, you want to rotate the screen to make you comfortable. For Automotive, mobile, TV or even if desktop. Just like xrandr for xserver. You want to get another resolution (mode), for example 1440x900, or 1920x1080. Monitor producer provide such things in order to let user use this. This interface provides such function dynamically to meet the requirement. Why would they use this interface? Dynamic mode setting for output will be provided to developer. Here is a general case: In window system or linux system, you want to change the resolution of your desktop at will. For example 1440x900 to 1920x1080, do you want to kill desktop server and then configure it and then restart desktop server. You will not, you just open the display configuration, and set it to 1920x1080 and then save it. The resolution of desktop will be changed. If you want another, same thing. Dynamic mode setting for output is found everywhere in matured window or linux desktop system. Providing this interface to embedded system, multi screen supported system will be fine. On Tue, Mar 4, 2014 at 9:07 PM, Wang, Quanxian quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote: Hi, All With the first version of randr protol, I got many useful idea and comments. Thanks. Before I send the email, I have make it happen in real world but need more deep testing. Here are new changes and idea for that protocol based on the idea and comments, welcome your input. 1) Unique operation issue Given that one client has two more threads to do mode setting on the same output at the same time, how to identify what response (done event) is belong to one or another request when they want to get response? This is a design flaw in the first version of randr protocol. The solution is to use the wayland/weston mechanism, every request will generate a resource which be used to send done event to the owner who start it. Owner could set the listener on that and keep tuning on the response event. For example In client: randr_transform = wl_randr_set_transform(randr.randr,wayland_output,argument.transform); /* Here will will add listen callback to get the response for this unique request */ wl_randr_add_listener(randr_transform, randr_transform_listener, randr); In compositor: randr_resource = wl_resource_create(client,wl_randr_interface,1, action); wl_randr_send_action_done(randr_resource, 1WL_RANDR_ACTION_TRANSFORM, ret, action); wl_resource_destroy(randr_resource); 2) Security and mess up issue Will take randr protocol implementation as a module or plugin. This will keep compositor clear and avoid messing up in compositor.c. Also it is will be fine for compositor when this could be public. The security should be a general issue for wayland instead of for randr protocol only. Take randr protocol as a module for user to determine if they want to public randr interface for their clients. Once security mechanism is built up in wayland, randr could adopt the mechanism to enhance the security of randr protocol. weston --tty=1 --modules=wrandr.so or set it in weston.ini like that [core] modules=wrandr.so 3) Group randr operations After talking with PQ, in order to avoid glitches, group operation is needed. However, if operate on two outputs more at one time, it will bring more issues which could not control. In this randr design, will not provide group operation on multiple outputs. We provide atomic operation on one output, multi outputs operation logic are left to designer/developers. Group operation on one output will be designed. For example, you can set mode, scale, and transform at one time with one randr request. 4) Configuration interface Weston randr protocol will be taken as configuration interface for output mode setting in wayland. So the permission for that will be strictly under the control. Before security mechanism is ready, randr module will be designed for compositor as a choice.
RE: [PATCH 1/6] Add weston randr protocol
Quanxian, I think what Jasper is getting at is the difference between a configuration interface and a client-facing interface. Unfortunately, in X the RandR interface was used in both capacities. Allow me to try and clerify this distinction. A client-facing interface is one that is detected and used by various clients. The intention of most client-facing interfaces is to make them general enough for all compositors and eventually get them mainlined into the core wayland protocol. If you are writing this kind of interface, you need to very specifically justify why clients need this kind of interface and not another. In particular, most clients have no buiseness changing the screen resolution. Some clients may cause a screen resolution change due to, for example, making their surface fullscreen. However, that is a very different thing from making arbitrary resolution changes. If you have a good reason for a client to make arbitrary RandR type changes other than dynamic configuration, you need to be very clear about why and we need to analize if there is a better way to do that than simply giving them access to RandR. When I say configuration interface I mean something that is intended for the express purpose of changing Weston's confguration dynamically. This could be a command-line or graphical utility that allows the user to select a new screen resolution, orientation, or whatever. If this is your intention, then you should probably use the weston_ prefix rather than the wl_ prefix and it should be considered weston-specific. Also, if possible, clients that use this interface should be launched from weston to ensure that they can only be used with the user's permission. I'm not sure how to make this work properly for a command-line client, but a graphical one could be special-cased inside weston to be allowed the interface. What I really don't think we need (and where I'm afraid this is headed) is a priviledged client-facing interface. I can see very little use for general modesetting interface that all compositors support. Output configuration GUI's aren't that hard to write and each compositor can have their own. I highly doubt someone will write a particularly spectacular third-party output configuration GUI that someone will want to use with GNOME or KDE. What about a standard command-line utility? Frankly, I can't see that ending well. The primary use for it would be by scripts and other clients completely breaking whatever security procedures we try to set up. So far, every use case you have given indicates that this is entirely a configuration interface. I'm not saying that you don't have a good reason for wanting to be able to change the output configuration. If what you're doing is something other than just on-the-fly weston configuration, I have a feeling that you have a more specific use in mind that would be better served by a more specific interface. Thanks, --Jason Ekstrand On Mar 4, 2014 9:22 PM, Wang, Quanxian quanxian.w...@intel.com wrote: From: wayland-devel-boun...@lists.freedesktop.org [mailto: wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jasper St. Pierre Sent: Wednesday, March 05, 2014 10:53 AM To: Wang, Quanxian Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Pekka Paalanen; Jason Ekstrand; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol So, before we go further on this, I need to ask three basic questions: what are the goals of this interface? Who is supposed to use this interface? Why would they use this interface? [Wang, Quanxian] What are the goals of this interface? The goal of this interface is to provide dynamic mode setting for output. Make wayland desktop configuration more flexible for scale, transform or mode setting. Who is supposed to use this interface? Any customer or user want to rotate, scale or mode the output when they needed. For example, Automotive, there are 2 screens, one is left another is on back, want to rotate the screen. You can sleep, stand, and more body postures, you want to rotate the screen to make you comfortable. For Automotive, mobile, TV or even if desktop. Just like xrandr for xserver. You want to get another resolution (mode), for example 1440x900, or 1920x1080. Monitor producer provide such things in order to let user use this. This interface provides such function dynamically to meet the requirement. Why would they use this interface? Dynamic mode setting for output will be provided to developer. Here is a general case: In window system or linux system, you want to change the resolution of your desktop at will. For example 1440x900 to 1920x1080, do you want to kill desktop server and then configure it and then restart desktop server. You will not, you just open the display configuration, and set it to 1920x1080 and then save it. The resolution of desktop will be changed. If you want another, same thing. Dynamic mode setting
Re: [PATCH 1/6] Add weston randr protocol
I'd also say that in the automotive case, you *don't* want arbitrary modesetting. The user of the infotainment system in your Land Rover will not want to change the display resolution from 800x600 to 1024x768; she won't choose it from a dropdown, and it's very likely she doesn't know what such functionality is. Such UIs are also fairly closely designed for various resolutions, with pixel-perfect graphics and so forth. Letting any client change the mode would be disaster, as now all the button sizes which were tested with various labels and font sizes and fingers are all different, and the rest of everything is chopped off! If some video player wants to go full-screen and all it has is a 800x600 surface, then let the compositor set the mode based on seeing that a full-screen surface has size 800x600, and we can natively set the mode, without the client ever communicating that it wants to do a mode change. On Tue, Mar 4, 2014 at 10:56 PM, Jason Ekstrand ja...@jlekstrand.netwrote: Quanxian, I think what Jasper is getting at is the difference between a configuration interface and a client-facing interface. Unfortunately, in X the RandR interface was used in both capacities. Allow me to try and clerify this distinction. A client-facing interface is one that is detected and used by various clients. The intention of most client-facing interfaces is to make them general enough for all compositors and eventually get them mainlined into the core wayland protocol. If you are writing this kind of interface, you need to very specifically justify why clients need this kind of interface and not another. In particular, most clients have no buiseness changing the screen resolution. Some clients may cause a screen resolution change due to, for example, making their surface fullscreen. However, that is a very different thing from making arbitrary resolution changes. If you have a good reason for a client to make arbitrary RandR type changes other than dynamic configuration, you need to be very clear about why and we need to analize if there is a better way to do that than simply giving them access to RandR. When I say configuration interface I mean something that is intended for the express purpose of changing Weston's confguration dynamically. This could be a command-line or graphical utility that allows the user to select a new screen resolution, orientation, or whatever. If this is your intention, then you should probably use the weston_ prefix rather than the wl_ prefix and it should be considered weston-specific. Also, if possible, clients that use this interface should be launched from weston to ensure that they can only be used with the user's permission. I'm not sure how to make this work properly for a command-line client, but a graphical one could be special-cased inside weston to be allowed the interface. What I really don't think we need (and where I'm afraid this is headed) is a priviledged client-facing interface. I can see very little use for general modesetting interface that all compositors support. Output configuration GUI's aren't that hard to write and each compositor can have their own. I highly doubt someone will write a particularly spectacular third-party output configuration GUI that someone will want to use with GNOME or KDE. What about a standard command-line utility? Frankly, I can't see that ending well. The primary use for it would be by scripts and other clients completely breaking whatever security procedures we try to set up. So far, every use case you have given indicates that this is entirely a configuration interface. I'm not saying that you don't have a good reason for wanting to be able to change the output configuration. If what you're doing is something other than just on-the-fly weston configuration, I have a feeling that you have a more specific use in mind that would be better served by a more specific interface. Thanks, --Jason Ekstrand On Mar 4, 2014 9:22 PM, Wang, Quanxian quanxian.w...@intel.com wrote: From: wayland-devel-boun...@lists.freedesktop.org [mailto: wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jasper St. Pierre Sent: Wednesday, March 05, 2014 10:53 AM To: Wang, Quanxian Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Pekka Paalanen; Jason Ekstrand; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol So, before we go further on this, I need to ask three basic questions: what are the goals of this interface? Who is supposed to use this interface? Why would they use this interface? [Wang, Quanxian] What are the goals of this interface? The goal of this interface is to provide dynamic mode setting for output. Make wayland desktop configuration more flexible for scale, transform or mode setting. Who is supposed to use this interface? Any customer or user want to rotate, scale or mode the
RE: [PATCH 1/6] Add weston randr protocol
From: wayland-devel-boun...@lists.freedesktop.org [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jasper St. Pierre Sent: Wednesday, March 05, 2014 12:51 PM To: Jason Ekstrand Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Pekka Paalanen; Zhang, Xiong Y; Wang, Quanxian Subject: Re: [PATCH 1/6] Add weston randr protocol I'd also say that in the automotive case, you *don't* want arbitrary modesetting. The user of the infotainment system in your Land Rover will not want to change the display resolution from 800x600 to 1024x768; she won't choose it from a dropdown, and it's very likely she doesn't know what such functionality is. [Wang, Quanxian] For example, someone like screen to contain more icons(big resolution) and someone like big icons in screen(small resolution). Resolution changed will be one way. I just say one way. In randr protocol, I don't want arbitrary. It is under the control. If security is fine, we could make it. If you really need it at once, just make it happen as a module. That is fine. Someone like 1024 or some one like 1920. It is different. I just provide one method for user or developer to choose under their requirement. Such UIs are also fairly closely designed for various resolutions, with pixel-perfect graphics and so forth. Letting any client change the mode would be disaster, as now all the button sizes which were tested with various labels and font sizes and fingers are all different, and the rest of everything is chopped off! [Wang, Quanxian] I don't' see xrandr is a disaster for xserver. It is a useful tool. Just like in window system, I will change the resolution from 1024 to 1920. One thing we need to be done is that it is must under the control. Basically we expected wayland could do that. Actually we have the same goal, let right client do right thing. But not means we should less some function. I expected wayland security will be powerful. If some video player wants to go full-screen and all it has is a 800x600 surface, then let the compositor set the mode based on seeing that a full-screen surface has size 800x600, and we can natively set the mode, without the client ever communicating that it wants to do a mode change. [Wang, Quanxian] Yes, surface full screen mode set could do that. But it is only for one surface. How about others surface. It is really different thing. Output configuration is for all things happened on the output. Surface configuration is for all things happened on the surface. One case, if it is pixel-perfect for graphics like you said, why monitor or screen producer provide more resolutions for that? Can you expect the reason? I think fix mode provided will be more cheap that more. Why producer like to do that? from my view, it is definitely the requirement of their customers. On Tue, Mar 4, 2014 at 10:56 PM, Jason Ekstrand ja...@jlekstrand.netmailto:ja...@jlekstrand.net wrote: Quanxian, I think what Jasper is getting at is the difference between a configuration interface and a client-facing interface. Unfortunately, in X the RandR interface was used in both capacities. Allow me to try and clerify this distinction. A client-facing interface is one that is detected and used by various clients. The intention of most client-facing interfaces is to make them general enough for all compositors and eventually get them mainlined into the core wayland protocol. If you are writing this kind of interface, you need to very specifically justify why clients need this kind of interface and not another. In particular, most clients have no buiseness changing the screen resolution. Some clients may cause a screen resolution change due to, for example, making their surface fullscreen. However, that is a very different thing from making arbitrary resolution changes. If you have a good reason for a client to make arbitrary RandR type changes other than dynamic configuration, you need to be very clear about why and we need to analize if there is a better way to do that than simply giving them access to RandR. When I say configuration interface I mean something that is intended for the express purpose of changing Weston's confguration dynamically. This could be a command-line or graphical utility that allows the user to select a new screen resolution, orientation, or whatever. If this is your intention, then you should probably use the weston_ prefix rather than the wl_ prefix and it should be considered weston-specific. Also, if possible, clients that use this interface should be launched from weston to ensure that they can only be used with the user's permission. I'm not sure how to make this work properly for a command-line client, but a graphical one could be special-cased inside weston to be allowed the interface. What I really don't think we need (and where I'm afraid this is headed) is a priviledged client-facing interface. I can see very little
RE: [PATCH 1/6] Add weston randr protocol
From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Wednesday, March 05, 2014 11:56 AM To: Wang, Quanxian Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Zhang, Xiong Y; Pekka Paalanen; Jasper St. Pierre Subject: RE: [PATCH 1/6] Add weston randr protocol Quanxian, I think what Jasper is getting at is the difference between a configuration interface and a client-facing interface. Unfortunately, in X the RandR interface was used in both capacities. Allow me to try and clerify this distinction. A client-facing interface is one that is detected and used by various clients. The intention of most client-facing interfaces is to make them general enough for all compositors and eventually get them mainlined into the core wayland protocol. If you are writing this kind of interface, you need to very specifically justify why clients need this kind of interface and not another. In particular, most clients have no buiseness changing the screen resolution. Some clients may cause a screen resolution change due to, for example, making their surface fullscreen. However, that is a very different thing from making arbitrary resolution changes. If you have a good reason for a client to make arbitrary RandR type changes other than dynamic configuration, you need to be very clear about why and we need to analize if there is a better way to do that than simply giving them access to RandR. When I say configuration interface I mean something that is intended for the express purpose of changing Weston's confguration dynamically. This could be a command-line or graphical utility that allows the user to select a new screen resolution, orientation, or whatever. If this is your intention, then you should probably use the weston_ prefix rather than the wl_ prefix and it should be considered weston-specific. Also, if possible, clients that use this interface should be launched from weston to ensure that they can only be used with the user's permission. I'm not sure how to make this work properly for a command-line client, but a graphical one could be special-cased inside weston to be allowed the interface. [Wang, Quanxian] yes. Weston randr protocol live with compositor. It will communicate with compositor to do that. weston_randr will be more reasonable. Thanks Jason What I really don't think we need (and where I'm afraid this is headed) is a priviledged client-facing interface. I can see very little use for general modesetting interface that all compositors support. Output configuration GUI's aren't that hard to write and each compositor can have their own. I highly doubt someone will write a particularly spectacular third-party output configuration GUI that someone will want to use with GNOME or KDE. What about a standard command-line utility? Frankly, I can't see that ending well. The primary use for it would be by scripts and other clients completely breaking whatever security procedures we try to set up. [Wang, Quanxian] Yes, permission control is the big stock on the way. As a script or application, you still need to communicate with compositor to do that. So far, every use case you have given indicates that this is entirely a configuration interface. I'm not saying that you don't have a good reason for wanting to be able to change the output configuration. If what you're doing is something other than just on-the-fly weston configuration, I have a feeling that you have a more specific use in mind that would be better served by a more specific interface. [Wang, Quanxian] not only for configuration. If configuration, just admin or root does that. It provides the mode set including transform, scale as a whole for output(screen) instead of for surface. But I acknowledge, it should be under the control. Thanks, --Jason Ekstrand On Mar 4, 2014 9:22 PM, Wang, Quanxian quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote: From: wayland-devel-boun...@lists.freedesktop.orgmailto:wayland-devel-boun...@lists.freedesktop.org [mailto:wayland-devel-boun...@lists.freedesktop.orgmailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jasper St. Pierre Sent: Wednesday, March 05, 2014 10:53 AM To: Wang, Quanxian Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.orgmailto:wayland-devel@lists.freedesktop.org; Pekka Paalanen; Jason Ekstrand; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol So, before we go further on this, I need to ask three basic questions: what are the goals of this interface? Who is supposed to use this interface? Why would they use this interface? [Wang, Quanxian] What are the goals of this interface? The goal of this interface is to provide dynamic mode setting for output. Make wayland desktop configuration more flexible for scale, transform or mode setting. Who is supposed to use this interface? Any customer or user want to rotate,
