[PATCH 1/6] Add weston randr protocol

[Jason Ekstrand]

On Mar 6, 2014 3:05 AM, "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
>
> 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.

Quanxian,
I think that for testing and configuration, this is fine.  In fact, when
testing my fullscreen shell I really wish I had a utility like that.  Right
now, with recent changes to toytoolkit, there's no good way to trigger a
dynamic mode-switch for testing.  If you go ahead and add this, I have a
couple suggestions:

1) Rename it weston_randr and make it weston-specific.

2) Make it a module and possibly require a command-line option to allow the
command-line utility to connect.  It's great for testing, but we want the
user to explicitly state that they want the command-line utility

3) It would be nice if we had a little GUI that gets launched priveledged
to change the mode.  This can be launched from weston directly, so we can
give it access to the private interface similar to the way the
screenshooter or desktop-shell is launched.  This wouldn't need the
security of a command-line option because it requires direct user
interaction and can't be executed from a script.

All that being said, I don't think you should expect GNOME, KDE, or the
others to be interested in this as a standard.  They have their own
mechanisms and GUI's for output configuration and I don't thin an output
configuration standard would be of any real use.

Hope that helps,
--Jason Ekstrand

>
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140306/20285d07/attachment-0001.html>