[PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

Thanks Pq's comment. 

By the way, if we make it as a configuration tools or testing protocol. Will it be fine or not? 

For example graphics QA testing, 
I just send a patch to bug fix the client apps because of output change. I use weston-wrandr to do the testing to make sure what I have done is right. If I have not this tool, I don't make sure how to test it. Because you need dynamically change rotate, transform, or mode set to make sure desktop shell could get the change and really works fine with new change.

Also this tool should be fine for wayland QA testing. 

Anyway, if you guys think it right for configuration or testing wayland graphics tools, that is fine. I can continue working on these patches instead of original idea to expose this to client to use.

Thanks for everyone's comment and help.

Regards

Quanxian Wang

>-----Original Message-----
>From: wayland-devel-bounces at lists.freedesktop.org
>[mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of Pekka
>Paalanen
>Sent: Thursday, March 06, 2014 4:25 PM
>To: Wang, Quanxian
>Cc: Hardening; Jasper St. Pierre; Matthias Clasen;
>wayland-devel at lists.freedesktop.org; Jason Ekstrand; Zhang, Xiong Y
>Subject: Re: [PATCH 1/6] Add weston randr protocol
>
>On Thu, 6 Mar 2014 03:01:11 +0000
>"Wang, Quanxian" <quanxian.wang at intel.com> wrote:
>
>> Except the comment below. I mention some points.
>>
>> 1) My idea:
>> My original idea is from xrandr of xserver. I just want to let xrandr
>> could be implemented in wayland. If no protocol is used, that is fine.
>> But no way to implement some function for example transform, scale,
>> mode set output. I have to create a protocol to communicate with
>> compositor and let compositor do that.
>
>Usually such configuration changes should originate within the compositor itself. In
>practice, it could be a special shell helper application (e.g. weston-desktop-shell)
>using a private protocol to communicate the intent of the user.
>
>The X server is different, because the X server is the same for every environment,
>so it must have standard protocol to do configuration changes. On Wayland this is
>not the case.
>
>> This protocol basically live with compositor. It also provides the
>> interface for library above to provide the randr function. For example
>> efl, gtk, or ... If you think it is to build the standard protocol,
>> that is fine. Anyway, my idea is that.
>
>The point is, those toolkit libraries should not have access to "wayland-randr" at all.
>It's not something a normal application should use.
>
>Again in X things are different because the RandR protocol must exist, but there is
>no easy way to make it restricted.
>
>> 2) About mode setting requirement:
>> Most of case, it is for configuration of output as a whole. Generally
>> it should be in setting panel for screen size, rotation, ...option
>> setting. The user cases I mentioned are related with that setting. Of
>> course you may prefer another way to implement.
>
>Such use cases would be perfectly served by the special shell client, which already
>needs a private, priviledged interface to the compositor anyway. This private
>interface is almost always environment specific.
>
>Wayland is not X; it is not intended that you could simply run a "panel program" at
>any time and expect it to add a well-functioning panel to the desktop. Such
>programs are special, so in the current design they are started directly by the
>compositor.
>
>>
>> 3) Security Issue:
>> I found Pq, Jason, Japsper, ... don't want to expose the interface
>> because of "at will, arbitrary or disaster or any client". Actually it
>> is security issue. That is fine. Yes, it really exists. We must be
>> careful for that. Firstly I take it as a module, let owner to
>> determine if he really need randr function. Secondly at the same time,
>> it will be convenient for us to update randr when new wayland security
>> control policy is ready.
>
>Sure, we just need to be clear first on what the intended use cases are, because
>they will affect the design a great deal, and even more on how well the proposal is
>received.
>
>> 4) Here I can share an security idea for such protocol. I just want to
>> show, if wayland provides such kind security checking, it will be
>> easily adopted by randr interface. Previous interface could be default
>> defined as general, other special could be identified as video or
>> root. Please do not focus on the role definition and I just take an
>> example.
>>
>> My security idea:
>> Add two attributes separately to wl_client, wl_randr interface.
>> wl_client has the user id and group id, wl_randr interface has an
>> access attribute (general user, video user, root/admin). if you are
>> afraid it is hacked, when you wl_closure_send, you can dynamically
>> generate user id and group id.
>>
>> In client:
>> wl_randr_set_mode(wl_wrandr_interface, ...) In compositor:
>> Uid = get_uid(client)
>> Gid = get_gid(client)
>> If (It_video_user(uid, gid,..) || !is_root_user(uid,gid..))
>> Wl_randr_send_permission("No permission to do that!\n");
>>
>> Continue...
>
>Except that checking for the UID and GID are completely useless: the compositor
>already runs as the user in most cases, and all clients will be run as the same user
>anyway, because no other user should have access to the compositor, unless they
>are already root.
>
>So the only thing you could do with this scheme is check for the root user. I do not
>think that is appropriate.
>
>Coming up with a workable security design is very hard. So far the only mechanism
>we have for granting special powers to a client is that it is started by the
>compositor directly from a well-known system path. This currently applies to the
>special shell helper programs.
>
>Just don't go there.
>
>First define the use cases clearly, and then if they are acceptable, we can find a
>way to expose the interface properly.
>
>> 5) At last I answer the questions raised by Pq for me.
>>
>> - Would you be happy with something that works for your specific use
>>   case only?
>> [Wang Quanxian]not happy, really not happy. I like what I do is
>> helpful for everyone.
>
>That's very cool. :-)
>
>> - Do you want to establish a universal standard, i.e. get this into
>>   Wayland core? If so, why?
>> [Wang Quanxian] No, it lives with compositor. Without compositor,
>> randr could do nothing.
>
>Well, it could be a Wayland core interface, but indeed, better not make it so.
>
>> - Do you want a sample implementation and the protocol be included in
>>   Weston specifically? If so, why?
>> [Wang Quanxian] weston or other compositor, any compositor which wants
>> that. I just provide a tool or protocol to implement randr function.
>
>"Implement randr function" does not answer the question "why".
>
>> The foremost, what is the use case?
>> [Wang Quanxian] still, more cases are listed. In window, in
>> linux(gnome, KDE), there is always some setting contains ration,
>> leftof, rightof, primary, slave, scale, transform, mode set. Is it not
>> use case? If not, why they are there? You know what I mean.
>
>Do you mean display configuration? That falls into the category "configuration",
>done by a special shell helper client or by the compositor itself. So this is a point for
>making it a generic example design of a _private_ output configuration protocol.
>
>> Currently tablet, TV, automotive have not such option, it is not user
>> don't want it. It is because no one provides that. Also it maybe some
>> other reason, some apps don't like that flexible mode setting because
>> it make it crashed or mess up.
>
>Well, yes. In those environments, the less there are changing variables, the
>cheaper it is to make a good, stable product. Also in many of those cases, changing
>the output configuration randr-like makes little sense to begin with.
>
>An option to change the GUI size or whatever must be built into the whole stack
>including the applications.
>
>A desktop computer is a quite different beast, because there no-one has exactly
>the same hardware setup as another person, and we just have to leave some
>room for manual fiddling just in case the defaults are not good for everyone.
>
>Note, that "wayland-randr" would be nothing towards normal applications, we
>already have the protocol to notify applications of output configuration changes
>for the desktop. (Not all of it applies to phone/TV/IVI/..., because they do not use
>xdg_shell protocol.)
>
>> >-----Original Message-----
>> >From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
>> >Sent: Wednesday, March 05, 2014 6:28 PM
>> >To: Wang, Quanxian
>> >Cc: Jasper St. Pierre; Jason Ekstrand; Zhang, Xiong Y; Hardening;
>> >Matthias Clasen; wayland-devel at lists.freedesktop.org
>> >Subject: Re: [PATCH 1/6] Add weston randr protocol
>> >
>> >On Wed, 5 Mar 2014 09:24:34 +0000
>> >"Wang, Quanxian" <quanxian.wang at intel.com> wrote:
>> >
>> >> Hi, Jasper & Jason
>> >>
>> >> In order to understand it more, I provide such cases.
>> >>
>> >>
>> >> 1)       One customer uses handset which OS using wayland. When he
>> >> open the handset, there is the menu screen which contain icons
>> >> list. Someone want to see 10 icons, someone wants to see 20 icons.
>> >> (one requirement, it really happens, at least when use my handset,
>> >> I like to see everything in one page or more). Surface mode set is
>> >> one way, output mode set is another way, apps setting is also
>> >> another way(font size or icon size).
>> >
>> >Runtime video mode switching in a phone? Is that even a thing? I
>> >mean, does the hardware even support anything but a single video mode
>> >for the panel?
>> >
>> >As for the UI size, that is much better handled at the drawing phase
>> >in applications, rather than by the scanout hardware doing scaling.
>> [Wang, Quanxian] Yes, I agree your point, in the drawing phase to do
>> that based on your parent layout(the parent at last point to
>> output/root window). if user open setting panel, and select screen
>> size setting to some mode, what happens on application?
>
>The application will receive a) wl_output.mode and possibly wl_output.geometry
>events, and b) configure events for all its shell surfaces via whatever the shell
>protocol is for the platform. The application is required to respond appropriately.
>
>Note, that this does _not_ happen for temporary video mode switches that may
>be triggered by the fullscreen protocol on desktop. This happens only for the
>non-temporary changes which require re-laying out the whole desktop and all
>applications.
>
>> Mess up or
>> disaster? I come across such thing in automotive. When we change
>> another mode to start weston, it works not good, mess up. we found the
>> size is defined as hard code. For example, width is 180x200, so apps
>> definitely define it as 180x200, if you change 200x200, mess up.
>
>That's not Wayland's problem, that is a problem in your testing and code review
>processes.
>
>Ok, so you want to make this a testing protocol interface? Then say so, that again
>changes the very purpose and requirements of this interface.
>Testing would actually be a good purpose.
>
>...
>> >> 4)       Another thinking
>> >> You use automotive or handset or TV, it is belong to you. There are
>> >> no existence to let arbitrary mode setting. If someone really do
>> >> that, that means your machine is attacked or hacked.
>> >> Automotive, handset, TV is a private thing which should not be
>> >> public to outside. It is not like server or server-like desktop.
>> >> Every client should have been  strictly controlled. Even if for
>> >> desktop, do you want anyone to access you at will?
>> >>
>> >> I don't expect wayland will be powerful in server. But it should be
>> >> a choice for embedded system or netbook or some small device which
>> >> is belong to private thing. It is under the control by user.
>> >
>> >Sorry, what?
>> [Wang, Quanxian] The owner of private device could have absolutely
>> permission to do what he want to do. User needs this, just do that if
>> he can control that. If could not, just disable that. It is based on
>> user case.
>
>Users do not use protocol interfaces. Applications use protocol interfaces, and
>users will install random applications doing random things if possible. Hence it is
>better to design interfaces so that they are hard to abuse for the wrong purposes.
>It also prevents bad application coding practices, even when the applications are
>pre-installed by the manufacturer.
>
>...
>> >To me it sounds like all the examples you gave are not suited to be
>> >implemented by video mode setting at all, and even less by a
>> >configuration protocol.
>> >
>> >Are you seriously going to use "wayland-randr" for these things?
>> [Wang, Quanxian] I take output as a whole to change the size of the
>> output. Basically the apps on this output should be changed
>> consistently. It is like you change the surface size, the subsurface
>> of this surface should be redraw with new size of parent.
>
>Sure, but you have the wrong approach. You cannot change physical properties
>with software, and explicitly coordinating all changes with all software involved will
>result in superior visual quality than using a hack like mode setting (we're not
>dealing with CRTs anymore).
>
>If you want to change the scale of the UI, that would be better integrated with the
>shell protocol, or environment specific configuration system. You will need your
>own shell protocol for everything anyway. The desktop shell protocol is designed
>for desktop computers, not phones, TVs, nor automotive.
>
>With all that said, there is still no obvious reason why a Wayland
>*client* should be able to set the output video mode in a production environment.
>If you have such a special environment where a process other than the Wayland
>server has to be in control of the video modes, then quite likely the best approach
>would be to design a protocol especially for that, Wayland or something else,
>whatever works best.
>
>Again we come back to the question, what do you really want to use the
>"wayland-randr" for?
>
>In my opinion, testing is a good reason, trying out output configurations easily is a
>good reason if there is no other way, but anything that would be routinely used in
>a production environment seems so far to be a bad reason. Or in other words:
>good for developers, possibly useful for administrators, not good for end users.
>
>Testing and trying out configurations are good use cases specifically for Weston,
>because Weston-desktop does not yet have a GUI to change the configuration at
>runtime. This means that the approach of putting the "wayland-randr" into a
>separate Weston plugin that is not loaded by default would be quite sufficient for
>security and acceptable in my opinion. Weston already has a test plugin that
>exposes an ugly protocol into Weston's guts, that is only used by 'make check',
>though that plugin is not installed with Weston.
>
>If testing and trying is sufficient for you, then you must explicitly say that is your
>purpose for this protocol to avoid all this fighting. :-)
>
>(Of course, even if it is just for testing and trying in Weston, nothing prevents you
>from building a proprietary product depending on it at runtime, even if it is a bad
>idea in general. Just leave that detail out, and you will have a lot smoother ride
>here. ;-)
>
>
>Thanks,
>pq
>_______________________________________________
>wayland-devel mailing list
>wayland-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/wayland-devel