[PATCH 1/6] Add weston randr protocol
ppaalanen at gmail.com
Thu Mar 6 00:25:16 PST 2014
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
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
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");
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
> - 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
"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
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
(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. ;-)
More information about the wayland-devel