RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com]
Sent: Friday, March 14, 2014 6:29 PM
To: Wang, Quanxian
Cc: Jasper St. Pierre; Hardening; wayland-devel@lists.freedesktop.org; Zhang,
Xiong Y; Matthias Clasen; Jason Ekstrand
Subject: Re: [PATCH 1/6] Add weston randr protocol

On Fri, 14 Mar 2014 09:34:28 +
Wang, Quanxian quanxian.w...@intel.com wrote:



 -Original Message-
 From: Pekka Paalanen [mailto:ppaala...@gmail.com]
 Sent: Friday, March 14, 2014 4:13 PM
 To: Wang, Quanxian
 Cc: Jasper St. Pierre; Hardening;
 wayland-devel@lists.freedesktop.org; Zhang, Xiong Y; Matthias Clasen;
 Jason Ekstrand
 Subject: Re: [PATCH 1/6] Add weston randr protocol
 
 On Fri, 14 Mar 2014 02:33:52 +
 Wang, Quanxian quanxian.w...@intel.com wrote:
 
  On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian
 quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote:
 
   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.
  
  I don't think that allowing to set only announced modes is a good idea.
  The RDP compositor is a good example where you can't know the
  supported modes (as nearly all modes can be supported).
  
  IIRC depending on the drivers, drm can also set arbitrary modes.
  [Wang, Quanxian] so, let user set the mode without limitation? Not
  sure if we
 should support that.
  Any comment for this requirement?
 
 Not a user, but an administrator or developer, remember?
 [Wang, Quanxian] got that.
 
 If we ignore all the no real hardware cases like RDP, VNC, and
 other stuff where the screen is actually a window on another system
 and so can be of any size, the following come to mind:
 
 - using the monitor hardware for scaling instead of the GPU
 
 - getting the native mode a display that has broken or missing EDID,
 as
   a workaround
 
 We have the support for arbitrary modelines already in weston's
 config file. Note that arbitrary size WxH is not enough, sometimes
 you need the whole timings to be custom. See the ModeLine directive
 for xorg.conf, and the arguments of xrandr --newmode.
 [Wang, Quanxian] Fine, drmModeSetCrtc will need more parameter which
 is from mode_info. like weston.ini or newmode in xrandr We create drm
modeinfo by these arguments. It need a new interface to do that. I will plan 
it in
new interface.
 
 While designing the interface, it would be nice to be able to easily
 reset to a known working mode, if the new mode doesn't work
 (modesetting succeeds, but the monitor does not like the signal).
 That means that if you first query/get the current mode, then switch
 to a new one, you can still switch back to the original exact mode
 even if it was a custom mode. There is probably a good reason why xrandr has
--newmode/addmode/mode instead of only --mode.
 [Wang, Quanxian] if you set the custom mode, basically we could not get the
result if it is right or not, it is based on the response from developer's 
view. But we
provide the interface to let them reset the mode.

Yes, I really mean the person looking at the monitor decides that it's not 
good,
need to set some known working mode before he can continue.
You've probably seen these click ok within 30 seconds if the picture looks ok 
now,
otherwise automatically reverts to the old mode dialogs.

 By the way, do we need provide a delete mode interface to delete the mode
which is not right determined by developer?

xrandr tool has it.

It's all up to you, really, if you see it as a feature that an administrator 
or developer
would use.

But do keep in mind, that protocol interface is not a user interface.
If someone makes GUI for weston-randr, and uses it to test a bunch of custom
modes where the last one actually works, it could be ugly if the GUI tool 
leaves a
bunch of non-working modelines in the server mode list. Then again, that list
probably gets wiped on server restart, and the admin is supposed to write the
good modeline into the server config file, so it becomes available by default.

And then there is the question, how far is it reasonable to go with this
weston-only tweaking protocol.

Like if you don't want to support custom modelines now, they can be added later
if needed, as long as the basic design here allows it. Do consider also your 
own
needs on IVI.

You should probably also look at the RandR X11 protocol, not what options 
xrandr
tool has. After all, you are designing a protocol here, not a user interface. 
xrandr is
just a user interface.
[Wang, Quanxian] Yes, I take randr X11 protocol as a basic reference and xrandr 
as a requirement to think about that. If we could provide randr function 
without protocol used, it will be the ideal case. However you know, we could 
not provide all without protocol

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Fri, 14 Mar 2014 02:33:52 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian 
 quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote:
 
  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.
 
 I don't think that allowing to set only announced modes is a good idea.
 The RDP compositor is a good example where you can't know the supported
 modes (as nearly all modes can be supported).
 
 IIRC depending on the drivers, drm can also set arbitrary modes.
 [Wang, Quanxian] so, let user set the mode without limitation? Not sure if we 
 should support that.
 Any comment for this requirement?

Not a user, but an administrator or developer, remember?

If we ignore all the no real hardware cases like RDP, VNC, and other
stuff where the screen is actually a window on another system and so
can be of any size, the following come to mind:

- using the monitor hardware for scaling instead of the GPU

- getting the native mode a display that has broken or missing EDID, as
  a workaround

We have the support for arbitrary modelines already in weston's config
file. Note that arbitrary size WxH is not enough, sometimes you need
the whole timings to be custom. See the ModeLine directive for
xorg.conf, and the arguments of xrandr --newmode.

While designing the interface, it would be nice to be able to easily
reset to a known working mode, if the new mode doesn't work
(modesetting succeeds, but the monitor does not like the signal). That
means that if you first query/get the current mode, then switch to a
new one, you can still switch back to the original exact mode even if
it was a custom mode. There is probably a good reason why xrandr has
--newmode/addmode/mode instead of only --mode.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com]
Sent: Friday, March 14, 2014 4:13 PM
To: Wang, Quanxian
Cc: Jasper St. Pierre; Hardening; wayland-devel@lists.freedesktop.org; Zhang,
Xiong Y; Matthias Clasen; Jason Ekstrand
Subject: Re: [PATCH 1/6] Add weston randr protocol

On Fri, 14 Mar 2014 02:33:52 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian
quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote:

  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.
 
 I don't think that allowing to set only announced modes is a good idea.
 The RDP compositor is a good example where you can't know the
 supported modes (as nearly all modes can be supported).
 
 IIRC depending on the drivers, drm can also set arbitrary modes.
 [Wang, Quanxian] so, let user set the mode without limitation? Not sure if we
should support that.
 Any comment for this requirement?

Not a user, but an administrator or developer, remember?
[Wang, Quanxian] got that.

If we ignore all the no real hardware cases like RDP, VNC, and other stuff 
where
the screen is actually a window on another system and so can be of any size, 
the
following come to mind:

- using the monitor hardware for scaling instead of the GPU

- getting the native mode a display that has broken or missing EDID, as
  a workaround

We have the support for arbitrary modelines already in weston's config file. 
Note
that arbitrary size WxH is not enough, sometimes you need the whole timings to
be custom. See the ModeLine directive for xorg.conf, and the arguments of 
xrandr
--newmode.
[Wang, Quanxian] Fine, drmModeSetCrtc will need more parameter which is from 
mode_info. like weston.ini or newmode in xrandr 
We create drm modeinfo by these arguments. It need a new interface to do that. 
I will plan it in new interface.

While designing the interface, it would be nice to be able to easily reset to a
known working mode, if the new mode doesn't work (modesetting succeeds, but
the monitor does not like the signal). That means that if you first query/get 
the
current mode, then switch to a new one, you can still switch back to the 
original
exact mode even if it was a custom mode. There is probably a good reason why
xrandr has --newmode/addmode/mode instead of only --mode.
[Wang, Quanxian] if you set the custom mode, basically we could not get the 
result if it is right or not, it is based on the response from developer's 
view. But we provide the interface to let them reset the mode. 
By the way, do we need provide a delete mode interface to delete the mode which 
is not right determined by developer?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Fri, 14 Mar 2014 09:34:28 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 
 
 -Original Message-
 From: Pekka Paalanen [mailto:ppaala...@gmail.com]
 Sent: Friday, March 14, 2014 4:13 PM
 To: Wang, Quanxian
 Cc: Jasper St. Pierre; Hardening; wayland-devel@lists.freedesktop.org; Zhang,
 Xiong Y; Matthias Clasen; Jason Ekstrand
 Subject: Re: [PATCH 1/6] Add weston randr protocol
 
 On Fri, 14 Mar 2014 02:33:52 +
 Wang, Quanxian quanxian.w...@intel.com wrote:
 
  On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian
 quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote:
 
   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.
  
  I don't think that allowing to set only announced modes is a good idea.
  The RDP compositor is a good example where you can't know the
  supported modes (as nearly all modes can be supported).
  
  IIRC depending on the drivers, drm can also set arbitrary modes.
  [Wang, Quanxian] so, let user set the mode without limitation? Not sure if 
  we
 should support that.
  Any comment for this requirement?
 
 Not a user, but an administrator or developer, remember?
 [Wang, Quanxian] got that.
 
 If we ignore all the no real hardware cases like RDP, VNC, and other stuff 
 where
 the screen is actually a window on another system and so can be of any size, 
 the
 following come to mind:
 
 - using the monitor hardware for scaling instead of the GPU
 
 - getting the native mode a display that has broken or missing EDID, as
   a workaround
 
 We have the support for arbitrary modelines already in weston's config file. 
 Note
 that arbitrary size WxH is not enough, sometimes you need the whole timings 
 to
 be custom. See the ModeLine directive for xorg.conf, and the arguments of 
 xrandr
 --newmode.
 [Wang, Quanxian] Fine, drmModeSetCrtc will need more parameter which is from 
 mode_info. like weston.ini or newmode in xrandr 
 We create drm modeinfo by these arguments. It need a new interface to do 
 that. I will plan it in new interface.
 
 While designing the interface, it would be nice to be able to easily reset 
 to a
 known working mode, if the new mode doesn't work (modesetting succeeds, but
 the monitor does not like the signal). That means that if you first 
 query/get the
 current mode, then switch to a new one, you can still switch back to the 
 original
 exact mode even if it was a custom mode. There is probably a good reason why
 xrandr has --newmode/addmode/mode instead of only --mode.
 [Wang, Quanxian] if you set the custom mode, basically we could not get the 
 result if it is right or not, it is based on the response from developer's 
 view. But we provide the interface to let them reset the mode. 

Yes, I really mean the person looking at the monitor decides that it's
not good, need to set some known working mode before he can continue.
You've probably seen these click ok within 30 seconds if the picture
looks ok now, otherwise automatically reverts to the old mode dialogs.

 By the way, do we need provide a delete mode interface to delete the mode 
 which is not right determined by developer?

xrandr tool has it.

It's all up to you, really, if you see it as a feature that an
administrator or developer would use.

But do keep in mind, that protocol interface is not a user interface.
If someone makes GUI for weston-randr, and uses it to test a bunch of
custom modes where the last one actually works, it could be ugly if the
GUI tool leaves a bunch of non-working modelines in the server mode
list. Then again, that list probably gets wiped on server restart, and
the admin is supposed to write the good modeline into the server config
file, so it becomes available by default.

And then there is the question, how far is it reasonable to go with
this weston-only tweaking protocol.

Like if you don't want to support custom modelines now, they can be
added later if needed, as long as the basic design here allows it. Do
consider also your own needs on IVI.

You should probably also look at the RandR X11 protocol, not what
options xrandr tool has. After all, you are designing a protocol here,
not a user interface. xrandr is just a user interface.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

From: magc...@gmail.com [mailto:magc...@gmail.com] On Behalf Of Jasper St. 
Pierre
Sent: Monday, March 10, 2014 10:42 AM
To: Wang, Quanxian
Cc: Hardening; wayland-devel@lists.freedesktop.org; Zhang, Xiong Y; Pekka 
Paalanen; Matthias Clasen; Jason Ekstrand
Subject: Re: [PATCH 1/6] Add weston randr protocol

There's two different things here. There's the protocol and the UI. (By UI I 
also mean a command-line tool like /usr/bin/xrandr, I just mean the way the 
user does a mode-set).
I think to build a good UI, we need a list of available modes that the user can 
choose from. Having a tool where the user enters two numbers, and then tells 
the user No, guess again if they entered the wrong numbers is bad user 
interface design.

But, as Hardening said, the protocol should allow setting modes that aren't in 
the advertised list.
[Wang, Quanxian] Sorry for response later. From command line tools, 
Weston-wrandr will provide the mode list instead of guessing what is in. you 
can firstly use 'weston-wrandr --output' to query all modes  of output. And 
then select one of them.
Of course, if you want to new a mode, that is fine. It is also reasonable for 
me.

On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian 
quanxian.w...@intel.commailto:quanxian.w...@intel.com wrote:

 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.

I don't think that allowing to set only announced modes is a good idea.
The RDP compositor is a good example where you can't know the supported
modes (as nearly all modes can be supported).

IIRC depending on the drivers, drm can also set arbitrary modes.
[Wang, Quanxian] so, let user set the mode without limitation? Not sure if we 
should support that.
Any comment for this requirement?


Regards

--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.orgmailto:wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



--
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

 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.

I don't think that allowing to set only announced modes is a good idea.
The RDP compositor is a good example where you can't know the supported
modes (as nearly all modes can be supported).

IIRC depending on the drivers, drm can also set arbitrary modes.
[Wang, Quanxian] so, let user set the mode without limitation? Not sure if we 
should support that.
Any comment for this requirement?


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 1/6] Add weston randr protocol

[Jasper St. Pierre]

There's two different things here. There's the protocol and the UI. (By
UI I also mean a command-line tool like /usr/bin/xrandr, I just mean the
way the user does a mode-set).

I think to build a good UI, we need a list of available modes that the user
can choose from. Having a tool where the user enters two numbers, and then
tells the user No, guess again if they entered the wrong numbers is bad
user interface design.

But, as Hardening said, the protocol should allow setting modes that aren't
in the advertised list.


On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian quanxian.w...@intel.comwrote:


  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.
 
 I don't think that allowing to set only announced modes is a good idea.
 The RDP compositor is a good example where you can't know the supported
 modes (as nearly all modes can be supported).
 
 IIRC depending on the drivers, drm can also set arbitrary modes.
 [Wang, Quanxian] so, let user set the mode without limitation? Not sure if
 we should support that.
 Any comment for this requirement?
 
 
 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




-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

 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:ppaala...@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@lists.freedesktop.org
 Subject: Re: [PATCH 1/6] Add weston randr protocol
 
 On Wed, 5 Mar 2014 09:24:34 +
 Wang, Quanxian quanxian.w...@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

RE: [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-boun...@lists.freedesktop.org
[mailto:wayland-devel-boun...@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@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 +
Wang, Quanxian quanxian.w...@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

Re: [PATCH 1/6] Add weston randr protocol

[Hardening]

Le 05/03/2014 03:07, Wang, Quanxian a écrit :

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.


I don't think that allowing to set only announced modes is a good idea. 
The RDP compositor is a good example where you can't know the supported 
modes (as nearly all modes can be supported).


IIRC depending on the drivers, drm can also set arbitrary modes.

[...]

Apart from that I think we really have to find a way to offer randr like 
interface, this leads to the security requirements that have been talked 
extensively here.


Haven't you noticed that most recent talks on big subjects always end 
with but what about security ?


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 1/6] Add weston randr protocol

[Hardening]

Le 05/03/2014 11:04, Pekka Paalanen a écrit :

On Wed, 5 Mar 2014 09:40:32 +
Wang, Quanxian quanxian.w...@intel.com wrote:


Just mention one thing

Pq:
But RandR is a disaster if random applications use it! Windows and
icons squashed into top-left corner, dialogs too large to fit on the
screen after the random application fails to restore the video mode,
or the picture just looking horrible and an average user not even
knowing why everything suddenly went ugly. [Wang, Quanxian] For this,
if you think it is disaster because of mode setting. It is a pity. If
the apps designer is careful, layout should be consistent with width
or height of output. In my testing for randr protocol, I found window
is designed to use width and height of output. Because it uses width
and height of output, but it doesn't care the change of
output(wl_output provides the mechanism to listen mode, scale
change). You can read my patch 6/6 for bug fix. It is just one fix.
It is the apps design flaw instead of wayland issue. Also you also
find 200 or 600 some hard code number is set.


Yeah, it looks like the patch 6/6 would be a nice fix, but I think you
should resend that alone, so it won't have to wait until the protocol
design is concluded. It's a stand-alone patch, right?



+1 for this one which is a very old bug.


--
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 1/6] Add weston randr protocol

[Jason Ekstrand]

On Mar 6, 2014 3:05 AM, Wang, Quanxian quanxian.w...@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-boun...@lists.freedesktop.org
 [mailto:wayland-devel-boun...@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@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 +
 Wang, Quanxian quanxian.w...@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

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Friday, March 07, 2014 11:21 AM
To: Wang, Quanxian
Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Jasper St. 
Pierre; Pekka Paalanen
Subject: RE: [PATCH 1/6] Add weston randr protocol


On Mar 6, 2014 3:05 AM, Wang, Quanxian 
quanxian.w...@intel.commailto:quanxian.w...@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.

[Wang, Quanxian] That is a good news. Thanks. I will continue working on that 
and provide the patches. Thanks for your response.

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-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 Pekka
 Paalanen
 Sent: Thursday, March 06, 2014 4:25 PM
 To: Wang, Quanxian
 Cc: Hardening; Jasper St. Pierre; Matthias Clasen;
 wayland-devel@lists.freedesktop.orgmailto:wayland-devel@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 +
 Wang, Quanxian quanxian.w...@intel.commailto:quanxian.w...@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

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

Hi,

first, could you please try to do proper quoting in emails so we can
clearly see what you wrote and what is a quotation, for more levels
than just the most recent email. See how I do it. Thanks.

I previously bypassed the question why, but in the below let's dig
deeped into that.


On Wed, 5 Mar 2014 05:48:33 +
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 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.

But RandR is a disaster if random applications use it! Windows and
icons squashed into top-left corner, dialogs too large to fit on the
screen after the random application fails to restore the video mode,
or the picture just looking horrible and an average user not even
knowing why everything suddenly went ugly.

I must agree with Jasper and Jason here. What you are doing is a
dynamic compositor configuration protocol. Configuration is for system
administrators, not for the average Joe User. Furthermore, configuration
changes made this way are not permanent, not with RandrR either (which
for X is a blessing, a reboot will fix a messed up configuration). That
means if Joe the User is lucky and finds a command line snippet to do
what he wants, the setting will be gone after a reboot.

Only the technical users may want to change the resolution, others
simply don't care as long as the picture is good. The non-technical
users probably would not know they could do that, or cannot even
imagine why they would ever want to do it.

If a graphical system wants to expose a setting like big icons vs.
small icons or whatever, they build that option into the window system
stack, which for something like automotive would include at least the
compositor, toolkits, and applications acting together to maintain the
quality of the UI. And that kind of cooperation is best done with a
specific protocol designed just for that, not a generic protocol,
because in such a stack all those programs are known in advance. On a
desktop system, such a setting is for the DE, is DE specific, and they
likely already have their own ways to communicate the settings.

Therefore it is very hard to see the benefit of a standardised
configuration protocol.

The way you are presenting this makes us assume, that you want to make
it a standard, rather than making something for your own use case and
asking for advice to make it better. This assumption colors our replies
very much.

 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

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

Just mention one thing

Pq:
But RandR is a disaster if random applications use it! Windows and icons 
squashed into top-left corner, dialogs too large to fit on the screen after the 
random application fails to restore the video mode, or the picture just looking 
horrible and an average user not even knowing why everything suddenly went ugly.
[Wang, Quanxian] For this, if you think it is disaster because of mode setting. 
It is a pity. If the apps designer is careful, layout should be consistent with 
width or height of output. In my testing for randr protocol, I found window is 
designed to use width and height of output. Because it uses width and height of 
output, but it doesn't care the change of output(wl_output provides the 
mechanism to listen mode, scale change). You can read my patch 6/6 for bug fix. 
It is just one fix. It is the apps design flaw instead of wayland issue. Also 
you also find 200 or 600 some hard code number is set.

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com] 
Sent: Wednesday, March 05, 2014 4:48 PM
To: Wang, Quanxian
Cc: Jasper St. Pierre; Jason Ekstrand; Hardening; Matthias Clasen; 
wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
Subject: Re: [PATCH 1/6] Add weston randr protocol

Hi,

first, could you please try to do proper quoting in emails so we can clearly 
see what you wrote and what is a quotation, for more levels than just the most 
recent email. See how I do it. Thanks.

I previously bypassed the question why, but in the below let's dig deeped 
into that.


On Wed, 5 Mar 2014 05:48:33 +
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 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.

But RandR is a disaster if random applications use it! Windows and icons 
squashed into top-left corner, dialogs too large to fit on the screen after the 
random application fails to restore the video mode, or the picture just looking 
horrible and an average user not even knowing why everything suddenly went ugly.

I must agree with Jasper and Jason here. What you are doing is a dynamic 
compositor configuration protocol. Configuration is for system administrators, 
not for the average Joe User. Furthermore, configuration changes made this way 
are not permanent, not with RandrR either (which for X is a blessing, a reboot 
will fix a messed up configuration). That means if Joe the User is lucky and 
finds a command line snippet to do what he wants, the setting will be gone 
after a reboot.

Only the technical users may want to change the resolution, others simply 
don't care as long as the picture is good. The non-technical users probably 
would not know they could do that, or cannot even imagine why they would ever 
want to do it.

If a graphical system wants to expose a setting like big icons vs.
small icons or whatever, they build that option into the window system stack, 
which for something like automotive would include at least the compositor, 
toolkits, and applications acting together to maintain the quality of the UI

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Wed, 5 Mar 2014 09:40:32 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 Just mention one thing
 
 Pq:
 But RandR is a disaster if random applications use it! Windows and
 icons squashed into top-left corner, dialogs too large to fit on the
 screen after the random application fails to restore the video mode,
 or the picture just looking horrible and an average user not even
 knowing why everything suddenly went ugly. [Wang, Quanxian] For this,
 if you think it is disaster because of mode setting. It is a pity. If
 the apps designer is careful, layout should be consistent with width
 or height of output. In my testing for randr protocol, I found window
 is designed to use width and height of output. Because it uses width
 and height of output, but it doesn't care the change of
 output(wl_output provides the mechanism to listen mode, scale
 change). You can read my patch 6/6 for bug fix. It is just one fix.
 It is the apps design flaw instead of wayland issue. Also you also
 find 200 or 600 some hard code number is set.

Yeah, it looks like the patch 6/6 would be a nice fix, but I think you
should resend that alone, so it won't have to wait until the protocol
design is concluded. It's a stand-alone patch, right?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Wed, 5 Mar 2014 09:24:34 +
Wang, Quanxian quanxian.w...@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.

 2)   Continue, customer click the web page apps, you could see
 the web contents. He can change the font size by setting web page(see
 clear or more contents). The same above, surface is one way, web
 setting another way, mode set for output is also a way.

I would think adjusting what the browser renders is the only sane way.
You definitely do not want a browser to control the video mode.

 3)   Ok, You can tell me, surface could do that, that is right.

No, abusing the fullscreen surface semantics for all that would be
wrong; the same as using video mode setting, in my opinion.

 You change menu screen surface, but at the same time you want to
 customer change the webpage surface with same action. Why do I say
 that? according to the custom, someone wants to see small or big,
 less or more, it will do the same thing in another apps. Generally
 when user have some sense for one apps to change the size of icon, it
 has the same feeling on other apps. Surface just update one surface,
 output will update all surfaces on the output. It is one shot thing.
 Surface mode set is one choice, why not provide output mode set to
 user? All done or part done, it is up to user. We just provide the
 choice.

This is not a thing that should be set via output properties. I
believe this should be done via the phone environment (cf. desktop
environment) specific protocols, which already need to handle a lot
more than that.

Output properties are about the physical output features, like the
size of a pixel. Those do not change with software usage.

 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?

 5)   Another thing, Please don't tell me customer doesn't know
 such functionality. Yes, from developer view, customer doesn't know
 what mode setting is. But when developer develops an application
 which use mode setting interface, it could be called another
 reasonable thing. For example, magnifier or smaller, or bigger, or
 little, or scaler... You know what I mean. The only thing is when you
 using your TV, handset, automotive, if you have the requirement to
 change the view of that.
 
 I just show my thought for this idea. Welcome any concern about
 that. :)

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?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] Add weston randr protocol

[Jason Ekstrand]

On Mar 5, 2014 4:27 AM, Pekka Paalanen ppaala...@gmail.com wrote:

 On Wed, 5 Mar 2014 09:24:34 +
 Wang, Quanxian quanxian.w...@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.

  2)   Continue, customer click the web page apps, you could see
  the web contents. He can change the font size by setting web page(see
  clear or more contents). The same above, surface is one way, web
  setting another way, mode set for output is also a way.

 I would think adjusting what the browser renders is the only sane way.
 You definitely do not want a browser to control the video mode.

  3)   Ok, You can tell me, surface could do that, that is right.

 No, abusing the fullscreen surface semantics for all that would be
 wrong; the same as using video mode setting, in my opinion.

  You change menu screen surface, but at the same time you want to
  customer change the webpage surface with same action. Why do I say
  that? according to the custom, someone wants to see small or big,
  less or more, it will do the same thing in another apps. Generally
  when user have some sense for one apps to change the size of icon, it
  has the same feeling on other apps. Surface just update one surface,
  output will update all surfaces on the output. It is one shot thing.
  Surface mode set is one choice, why not provide output mode set to
  user? All done or part done, it is up to user. We just provide the
  choice.

 This is not a thing that should be set via output properties. I
 believe this should be done via the phone environment (cf. desktop
 environment) specific protocols, which already need to handle a lot
 more than that.

 Output properties are about the physical output features, like the
 size of a pixel. Those do not change with software usage.

Allow me to add just a bit to what Pekka said above.  10 or 15 years ago
when people were using CRT monitors and drawing icons at multiple
resolutions was expensive, mode-setting made sense.  It provided a simple
way to physically scale the UI without making more work for the hardware.
However, in today's world of LCD's this is not the case.

First of all, this is because, on an LCD, there is no such thing as mode
setting.  CRT monitors could actually be run at multiple different modes by
adjusting how the ray scanned across the glass at the front of the
monitor.  With an LCD, all you can do is fake a different mode by scaling
the output to more-or-less fill the monitor.  This is what your LCD does
when you plug something in via VGA and it provides a smaller picture.  If,
on the other hand, you plug it in via DVI there's a decent chance that it
never gets sent a different mode at all but that the GPU siliently scales
the picture.  The reason for this is that the *only* way to get a different
mode is to scale the picture and the GPU will do a better job than the
monitor.  In other words,  there is nosuch thing as modesetting on an LCD,
only scaling.

What it sounds like your user wants is not modesetting but a make
everything bigger/smaller option.  Yes, one way to implement this would be
some fake modesetting system where they set the screen resolution.
However, that is going to end with the applications drawing at one
resolution, then the compositor or something scaling it to another
resolution and everything looking fuzzy.  The user does *not* want fuzzy.
A far better option would be to provide a configuration interface that ties
your options panel to your toolkit that allows them to set some sort of a
universal size factor that affects icon resource sizes, font sizes, etc.
Then the clients will simply all render with bigger icons and text.  Since
you are working on a controlled system, you should be able to ensure that
this happens.  You will get your make everything bigger option and the
user will get a far better experience because everything will look nice and
crisp.

It might be worth you looking at how Android solves this problem.  They
have devices with everything between 100 DPI and 450 DPI and the UI
more-or-less looks the same across devices.  They simply scale the icons
and text as needed.  What you are doing might be the opposite (different UI
size on the same hardware) but the 

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com]
Sent: Wednesday, March 05, 2014 6:04 PM
To: Wang, Quanxian
Cc: Jasper St. Pierre; Jason Ekstrand; Hardening; Matthias Clasen;
wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
Subject: Re: [PATCH 1/6] Add weston randr protocol

On Wed, 5 Mar 2014 09:40:32 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 Just mention one thing

 Pq:
 But RandR is a disaster if random applications use it! Windows and
 icons squashed into top-left corner, dialogs too large to fit on the
 screen after the random application fails to restore the video mode,
 or the picture just looking horrible and an average user not even
 knowing why everything suddenly went ugly. [Wang, Quanxian] For this,
 if you think it is disaster because of mode setting. It is a pity. If
 the apps designer is careful, layout should be consistent with width
 or height of output. In my testing for randr protocol, I found window
 is designed to use width and height of output. Because it uses width
 and height of output, but it doesn't care the change of
 output(wl_output provides the mechanism to listen mode, scale change).
 You can read my patch 6/6 for bug fix. It is just one fix.
 It is the apps design flaw instead of wayland issue. Also you also
 find 200 or 600 some hard code number is set.

Yeah, it looks like the patch 6/6 would be a nice fix, but I think you should 
resend
that alone, so it won't have to wait until the protocol design is concluded. 
It's a
stand-alone patch, right?
[Wang, Quanxian] yes. It is found when I do testing. But not related with the 
weston randr protocol.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

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.

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.

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. 

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.

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...


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.

- 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.

- 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.

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. 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.

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@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@lists.freedesktop.org
Subject: Re: [PATCH 1/6] Add weston randr protocol

On Wed, 5 Mar 2014 09:24:34 +
Wang, Quanxian quanxian.w...@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?
Mess up or disaster? I come across such thing

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

From: wayland-devel-boun...@lists.freedesktop.org 
[mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jason Ekstrand
Sent: Wednesday, March 05, 2014 9:57 PM
To: Pekka Paalanen
Cc: Hardening; Jasper St. Pierre; Matthias Clasen; 
wayland-devel@lists.freedesktop.org; Zhang, Xiong Y; Wang, Quanxian
Subject: Re: [PATCH 1/6] Add weston randr protocol


On Mar 5, 2014 4:27 AM, Pekka Paalanen 
ppaala...@gmail.commailto:ppaala...@gmail.com wrote:

 On Wed, 5 Mar 2014 09:24:34 +
 Wang, Quanxian quanxian.w...@intel.commailto:quanxian.w...@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.

  2)   Continue, customer click the web page apps, you could see
  the web contents. He can change the font size by setting web page(see
  clear or more contents). The same above, surface is one way, web
  setting another way, mode set for output is also a way.

 I would think adjusting what the browser renders is the only sane way.
 You definitely do not want a browser to control the video mode.

  3)   Ok, You can tell me, surface could do that, that is right.

 No, abusing the fullscreen surface semantics for all that would be
 wrong; the same as using video mode setting, in my opinion.

  You change menu screen surface, but at the same time you want to
  customer change the webpage surface with same action. Why do I say
  that? according to the custom, someone wants to see small or big,
  less or more, it will do the same thing in another apps. Generally
  when user have some sense for one apps to change the size of icon, it
  has the same feeling on other apps. Surface just update one surface,
  output will update all surfaces on the output. It is one shot thing.
  Surface mode set is one choice, why not provide output mode set to
  user? All done or part done, it is up to user. We just provide the
  choice.

 This is not a thing that should be set via output properties. I
 believe this should be done via the phone environment (cf. desktop
 environment) specific protocols, which already need to handle a lot
 more than that.

 Output properties are about the physical output features, like the
 size of a pixel. Those do not change with software usage.

Allow me to add just a bit to what Pekka said above.  10 or 15 years ago when 
people were using CRT monitors and drawing icons at multiple resolutions was 
expensive, mode-setting made sense.  It provided a simple way to physically 
scale the UI without making more work for the hardware.  However, in today's 
world of LCD's this is not the case.

First of all, this is because, on an LCD, there is no such thing as mode 
setting.  CRT monitors could actually be run at multiple different modes by 
adjusting how the ray scanned across the glass at the front of the monitor.  
With an LCD, all you can do is fake a different mode by scaling the output to 
more-or-less fill the monitor.  This is what your LCD does when you plug 
something in via VGA and it provides a smaller picture.  If, on the other hand, 
you plug it in via DVI there's a decent chance that it never gets sent a 
different mode at all but that the GPU siliently scales the picture.  The 
reason for this is that the *only* way to get a different mode is to scale the 
picture and the GPU will do a better job than the monitor.  In other words,  
there is nosuch thing as modesetting on an LCD, only scaling.

What it sounds like your user wants is not modesetting but a make everything 
bigger/smaller option.  Yes, one way to implement this would be some fake 
modesetting system where they set the screen resolution.  However, that is 
going to end with the applications drawing at one resolution, then the 
compositor or something scaling it to another resolution and everything looking 
fuzzy.  The user does *not* want fuzzy.  A far better option would be to 
provide a configuration interface that ties your options panel to your toolkit 
that allows them to set some sort of a universal size factor that affects icon 
resource sizes, font sizes, etc.  Then the clients will simply all render with 
bigger icons and text.  Since you are working on a controlled system, you 
should be able to ensure that this happens.  You will get

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

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

[Jasper St. Pierre]

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: wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

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

[Jason Ekstrand]

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

[Jasper St. Pierre]

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

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

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

[Wang, Quanxian]

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

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com] 
Sent: Thursday, February 27, 2014 3:28 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 11:28:00 +0800
Quanxian Wang quanxian.w...@intel.com wrote:

 Weston protocol wrandr will provide interface to
 1) set output mode
 2) set output transform
 3) move output to relative position
 4) provide disconnected display port information
 
 *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.

Hi,

like I said in my other reply, this is a configuration interface, not something 
for all applications to use. Protocol comments below assuming, that this will 
be a configuration interface and that the generic idea is acceptable.

 Signed-off-by: Quanxian Wang quanxian.w...@intel.com
 Reviewed-by: Zhang, Xiong Y xiong.y.zh...@intel.com
 ---
  protocol/Makefile.am |   1 +
  protocol/randr.xml   | 151 
 +++
  2 files changed, 152 insertions(+)
  create mode 100644 protocol/randr.xml
 
 diff --git a/protocol/Makefile.am b/protocol/Makefile.am index 
 5e331a7..df2e070 100644
 --- a/protocol/Makefile.am
 +++ b/protocol/Makefile.am
 @@ -5,6 +5,7 @@ protocol_sources =\
   text.xml\
   input-method.xml\
   workspaces.xml  \
 + randr.xml   \
   text-cursor-position.xml\
   wayland-test.xml\
   xdg-shell.xml   \
 diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode 
 100644 index 000..f15e87a
 --- /dev/null
 +++ b/protocol/randr.xml
 @@ -0,0 +1,151 @@
 +?xml version=1.0 encoding=UTF-8? protocol name=randr
 +
 +  copyright
 +Copyright (c) 2012-2013 Collabora, Ltd.

Fix this.

 +
 +Permission to use, copy, modify, distribute, and sell this
 +software and its documentation for any purpose is hereby granted
 +without fee, provided that the above copyright notice appear in
 +all copies and that both that copyright notice and this permission
 +notice appear in supporting documentation, and that the name of
 +the copyright holders not be used in advertising or publicity
 +pertaining to distribution of the software without specific,
 +written prior permission.  The copyright holders make no
 +representations about the suitability of this software for any
 +purpose.  It is provided as is without express or implied
 +warranty.
 +
 +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
 +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
 +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 +THIS SOFTWARE.
 +  /copyright
 +
 +  interface name=wl_randr version=1
 +description summary=randr
 +  The global interface exposing randr capabilities.
 +  As a wl_randr, that provides the interfaces for apps to more operations
 +  on output.
 +
 +  The aim of wl_randr is to get modes list, choose preferred mode,
 +  layout the output including position, rotate, and en/disable.
 +  The idea is from xrandr protocoal of xserver. It is very convenient for
 +  weston/wayland user to operates on mode setting of output.
 +/description
 +
 +enum name=error
 +  entry name=bad_randr value=0
 + summary=the to-be wl_randr is invalid/
 +/enum
 +
 +request name=destroy type=destructor
 +  description summary=unbind from the wl_randr interface
 + Informs the server that the client will not be using this
 + protocol object anymore. This does not affect any other
 + objects, wl_randr objects included.
 +  /description
 +/request
 +
 +request name=set_mode
 +  description summary=set the mode of output
 + set the mode of output
 +  /description
 +  arg name=output type=object interface=wl_output
 +   summary=the output object/
 +  arg name=width type=int/
 +  arg name=height type=int/
 +  arg name=refresh type=int/
 +/request

Since you require a wl_output, there does not seem to be a way to force a 
disconnected output on? Should there be? Why else would you need a way to list 
disconnected outputs?
[Wang, Quanxian] list disconnected outputs, just let user get to know the 
status of display port in this current machine. Who are connected, who

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

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, Quanxian
 Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
 Subject: Re: [PATCH 1/6] Add weston randr protocol
 
 On Thu, 27 Feb 2014 11:28:00 +0800
 Quanxian Wang quanxian.w...@intel.com wrote:
 
  Weston protocol wrandr will provide interface to
  1) set output mode
  2) set output transform
  3) move output to relative position
  4) provide disconnected display port information
  
  *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.
 
 Hi,
 
 like I said in my other reply, this is a configuration interface, not
 something for all applications to use. Protocol comments below
 assuming, that this will be a configuration interface and that the
 generic idea is acceptable.
 
  Signed-off-by: Quanxian Wang quanxian.w...@intel.com
  Reviewed-by: Zhang, Xiong Y xiong.y.zh...@intel.com
  ---
   protocol/Makefile.am |   1 +
   protocol/randr.xml   | 151
  +++ 2 files
  changed, 152 insertions(+) create mode 100644 protocol/randr.xml
  
  diff --git a/protocol/Makefile.am b/protocol/Makefile.am index 
  5e331a7..df2e070 100644
  --- a/protocol/Makefile.am
  +++ b/protocol/Makefile.am
  @@ -5,6 +5,7 @@ protocol_sources =  \
  text.xml\
  input-method.xml\
  workspaces.xml  \
  +   randr.xml   \
  text-cursor-position.xml\
  wayland-test.xml\
  xdg-shell.xml   \
  diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode 
  100644 index 000..f15e87a
  --- /dev/null
  +++ b/protocol/randr.xml
  @@ -0,0 +1,151 @@
  +?xml version=1.0 encoding=UTF-8? protocol name=randr
  +
  +  copyright
  +Copyright (c) 2012-2013 Collabora, Ltd.
 
 Fix this.
 
  +
  +Permission to use, copy, modify, distribute, and sell this
  +software and its documentation for any purpose is hereby
  granted
  +without fee, provided that the above copyright notice appear in
  +all copies and that both that copyright notice and this
  permission
  +notice appear in supporting documentation, and that the name of
  +the copyright holders not be used in advertising or publicity
  +pertaining to distribution of the software without specific,
  +written prior permission.  The copyright holders make no
  +representations about the suitability of this software for any
  +purpose.  It is provided as is without express or implied
  +warranty.
  +
  +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO
  THIS
  +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
  AND
  +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR
  ANY
  +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
  WHETHER IN
  +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
  +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
  +THIS SOFTWARE.
  +  /copyright
  +
  +  interface name=wl_randr version=1
  +description summary=randr
  +  The global interface exposing randr capabilities.
  +  As a wl_randr, that provides the interfaces for apps to more
  operations
  +  on output.
  +
  +  The aim of wl_randr is to get modes list, choose preferred
  mode,
  +  layout the output including position, rotate, and en/disable.
  +  The idea is from xrandr protocoal of xserver. It is very
  convenient for
  +  weston/wayland user to operates on mode setting of output.
  +/description
  +
  +enum name=error
  +  entry name=bad_randr value=0
  + summary=the to-be wl_randr is invalid/
  +/enum
  +
  +request name=destroy type=destructor
  +  description summary=unbind from the wl_randr interface
  +   Informs the server that the client will not be using this
  +   protocol object anymore. This does not affect any other
  +   objects, wl_randr objects included.
  +  /description
  +/request
  +
  +request name=set_mode
  +  description summary=set the mode of output
  +   set the mode of output
  +  /description
  +  arg name=output type=object interface=wl_output
  +   summary=the output object/
  +  arg name=width type=int/
  +  arg name=height type=int/
  +  arg name=refresh type=int/
  +/request
 
 Since you require a wl_output, there does not seem to be a way to
 force a disconnected output on? Should there be? Why else would you
 need

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-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, Quanxian
 Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
 Subject: Re: [PATCH 1/6] Add weston randr protocol
 
 On Thu, 27 Feb 2014 11:28:00 +0800
 Quanxian Wang quanxian.w...@intel.com wrote:
 
  Weston protocol wrandr will provide interface to
  1) set output mode
  2) set output transform
  3) move output to relative position
  4) provide disconnected display port information
  
  *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.
 
 Hi,
 
 like I said in my other reply, this is a configuration interface, not 
 something for all applications to use. Protocol comments below 
 assuming, that this will be a configuration interface and that the 
 generic idea is acceptable.
 
  Signed-off-by: Quanxian Wang quanxian.w...@intel.com
  Reviewed-by: Zhang, Xiong Y xiong.y.zh...@intel.com
  ---
   protocol/Makefile.am |   1 +
   protocol/randr.xml   | 151
  +++ 2 files
  changed, 152 insertions(+) create mode 100644 protocol/randr.xml
  
  diff --git a/protocol/Makefile.am b/protocol/Makefile.am index
  5e331a7..df2e070 100644
  --- a/protocol/Makefile.am
  +++ b/protocol/Makefile.am
  @@ -5,6 +5,7 @@ protocol_sources =  \
  text.xml\
  input-method.xml\
  workspaces.xml  \
  +   randr.xml   \
  text-cursor-position.xml\
  wayland-test.xml\
  xdg-shell.xml   \
  diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode
  100644 index 000..f15e87a
  --- /dev/null
  +++ b/protocol/randr.xml
  @@ -0,0 +1,151 @@
  +?xml version=1.0 encoding=UTF-8? protocol name=randr
  +
  +  copyright
  +Copyright (c) 2012-2013 Collabora, Ltd.
 
 Fix this.
 
  +
  +Permission to use, copy, modify, distribute, and sell this
  +software and its documentation for any purpose is hereby
  granted
  +without fee, provided that the above copyright notice appear in
  +all copies and that both that copyright notice and this
  permission
  +notice appear in supporting documentation, and that the name of
  +the copyright holders not be used in advertising or publicity
  +pertaining to distribution of the software without specific,
  +written prior permission.  The copyright holders make no
  +representations about the suitability of this software for any
  +purpose.  It is provided as is without express or implied
  +warranty.
  +
  +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO
  THIS
  +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
  AND
  +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR
  ANY
  +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
  WHETHER IN
  +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
  +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
  +THIS SOFTWARE.
  +  /copyright
  +
  +  interface name=wl_randr version=1
  +description summary=randr
  +  The global interface exposing randr capabilities.
  +  As a wl_randr, that provides the interfaces for apps to more
  operations
  +  on output.
  +
  +  The aim of wl_randr is to get modes list, choose preferred
  mode,
  +  layout the output including position, rotate, and en/disable.
  +  The idea is from xrandr protocoal of xserver. It is very
  convenient for
  +  weston/wayland user to operates on mode setting of output.
  +/description
  +
  +enum name=error
  +  entry name=bad_randr value=0
  + summary=the to-be wl_randr is invalid/
  +/enum
  +
  +request name=destroy type=destructor
  +  description summary=unbind from the wl_randr interface
  +   Informs the server that the client will not be using this
  +   protocol object anymore. This does not affect any other
  +   objects, wl_randr objects included.
  +  /description
  +/request
  +
  +request name=set_mode
  +  description summary=set the mode of output
  +   set the mode of output
  +  /description
  +  arg name=output type=object interface=wl_output
  +   summary=the output object/
  +  arg

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

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, Quanxian
  Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
  Subject: Re: [PATCH 1/6] Add weston randr protocol
  
  On Thu, 27 Feb 2014 11:28:00 +0800
  Quanxian Wang quanxian.w...@intel.com wrote:
  
   Weston protocol wrandr will provide interface to
   1) set output mode
   2) set output transform
   3) move output to relative position
   4) provide disconnected display port information
   
   *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.
  
  Hi,
  
  like I said in my other reply, this is a configuration interface,
  not something for all applications to use. Protocol comments below 
  assuming, that this will be a configuration interface and that the 
  generic idea is acceptable.
...
  If I change the mode on two different outputs, how do I know which 
  action_done corresponds to which request? [Wang, Quanxian] right,
  add wl_output parameter.
 
 No. If I do two mode set operations on the same wl_output, then again
 I would not know which answer was for which. [Wang, Quanxian] I know
 you mean. Yes, if the same client has more threads which send mode
 change at the same time, we have to use unique number to stand for
 every operation.

That unique number could be a serial, but here more appropriate is a
unique number for each request. You can let Wayland do all the unique
number management for you by using the feedback object design I
referred to below. After all, a Wayland protocol object is essentially
just a unique number. They are very cheap.

That is why you almost never need to manually fiddle with unique
numbers in the protocol.

 Instead, a generic pattern for this kind of return data is to let
 the original request also create a feedback protocol object. This
 object is unique to the request that was sent, and can deliver any
 return data without any ambiguity. An example of a feedback object is
 wl_callback, except it can only deliver done, not yes/no; not
 delivering anything will cause problems. [Wang, Quanxian] Good,
 thanks.
 
  
  What if move succeeds but mode change fails? Wouldn't that leave
  the output in an unwanted state which is neither the original nor
  the wanted setting? [Wang, Quanxian] one by one. Not support
  complex. If you have such case, have to turn back. Call another
  move back. But firstly make sure the previous is successful.
 
 That will require a lot of roundtrips, and it essentially forces the
 compositor to show all the intermediate steps on the monitors. IOW,
 that is designed to be both slow and glitchy. That's not how you
 should do dynamic mode setting. I think you are going to need atomic
 group operations. [Wang, Quanxian] Yes, we could provide a request
 with more parameters setting(group operations). Just like many
 parameters in weston_output_switch_mode.

Except you would need to let it cover an arbitrary number of outputs in
one go. That means that you will need something like what
wl_surface.commit does. Having a request with a huge number of
arguments is not only ugly but inflexible, and cannot be extended in
the future.

  The solution to this would tie in with the solution to take changes 
  atomic. For instance, to prepare for a configuration change, one
  might create a change object in the protocol, store all changes in
  that object, and then commit that set of changes atomically. Then
  have one return value: the whole set either succeeds or fails.
  
  I guess you could look for inspiration in the DRM atomic mode
  setting API. I don't know how the RandR X11 protocol works, if that
  would be a good example also.

Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

-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, Quanxian
  Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y
  Subject: Re: [PATCH 1/6] Add weston randr protocol
  
  On Thu, 27 Feb 2014 11:28:00 +0800
  Quanxian Wang quanxian.w...@intel.com wrote:
  
   Weston protocol wrandr will provide interface to
   1) set output mode
   2) set output transform
   3) move output to relative position
   4) provide disconnected display port information
   
   *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.
  
  Hi,
  
  like I said in my other reply, this is a configuration interface, 
  not something for all applications to use. Protocol comments below 
  assuming, that this will be a configuration interface and that the 
  generic idea is acceptable.
...
  If I change the mode on two different outputs, how do I know which 
  action_done corresponds to which request? [Wang, Quanxian] right, 
  add wl_output parameter.
 
 No. If I do two mode set operations on the same wl_output, then again 
 I would not know which answer was for which. [Wang, Quanxian] I know 
 you mean. Yes, if the same client has more threads which send mode 
 change at the same time, we have to use unique number to stand for 
 every operation.

That unique number could be a serial, but here more appropriate is a unique 
number for each request. You can let Wayland do all the unique number 
management for you by using the feedback object design I referred to below. 
After all, a Wayland protocol object is essentially just a unique number. They 
are very cheap.

That is why you almost never need to manually fiddle with unique numbers in 
the protocol.

 Instead, a generic pattern for this kind of return data is to let 
 the original request also create a feedback protocol object. This 
 object is unique to the request that was sent, and can deliver any 
 return data without any ambiguity. An example of a feedback object is 
 wl_callback, except it can only deliver done, not yes/no; not 
 delivering anything will cause problems. [Wang, Quanxian] Good, 
 thanks.
 
  
  What if move succeeds but mode change fails? Wouldn't that leave the 
  output in an unwanted state which is neither the original nor the 
  wanted setting? [Wang, Quanxian] one by one. Not support complex. If 
  you have such case, have to turn back. Call another move back. But 
  firstly make sure the previous is successful.
 
 That will require a lot of roundtrips, and it essentially forces the 
 compositor to show all the intermediate steps on the monitors. IOW, 
 that is designed to be both slow and glitchy. That's not how you 
 should do dynamic mode setting. I think you are going to need atomic 
 group operations. [Wang, Quanxian] Yes, we could provide a request 
 with more parameters setting(group operations). Just like many 
 parameters in weston_output_switch_mode.

Except you would need to let it cover an arbitrary number of outputs in one go. 
That means that you will need something like what wl_surface.commit does. 
Having a request with a huge number of arguments is not only ugly but 
inflexible, and cannot be extended in the future.
[Wang, Quanxian] Agree, I have found that when using this. Basically I want to 
add transform parameter, at last I give up. because it is complex, also ugly, 
and not readable. :)

  The solution to this would tie in with the solution to take changes 
  atomic. For instance, to prepare for a configuration change, one 
  might create a change object in the protocol, store all changes in 
  that object, and then commit that set of changes atomically. Then 
  have one return value: the whole set either succeeds or fails.
  
  I guess you could look for inspiration in the DRM atomic mode 
  setting API. I don't know how the RandR X11 protocol works, if that 
  would be a good example also.

Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Thu, 27 Feb 2014 11:28:00 +0800
Quanxian Wang quanxian.w...@intel.com wrote:

 Weston protocol wrandr will provide interface to
 1) set output mode
 2) set output transform
 3) move output to relative position
 4) provide disconnected display port information
 
 *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.

Hi,

like I said in my other reply, this is a configuration interface, not
something for all applications to use. Protocol comments below assuming,
that this will be a configuration interface and that the generic idea
is acceptable.

 Signed-off-by: Quanxian Wang quanxian.w...@intel.com
 Reviewed-by: Zhang, Xiong Y xiong.y.zh...@intel.com
 ---
  protocol/Makefile.am |   1 +
  protocol/randr.xml   | 151 
 +++
  2 files changed, 152 insertions(+)
  create mode 100644 protocol/randr.xml
 
 diff --git a/protocol/Makefile.am b/protocol/Makefile.am
 index 5e331a7..df2e070 100644
 --- a/protocol/Makefile.am
 +++ b/protocol/Makefile.am
 @@ -5,6 +5,7 @@ protocol_sources =\
   text.xml\
   input-method.xml\
   workspaces.xml  \
 + randr.xml   \
   text-cursor-position.xml\
   wayland-test.xml\
   xdg-shell.xml   \
 diff --git a/protocol/randr.xml b/protocol/randr.xml
 new file mode 100644
 index 000..f15e87a
 --- /dev/null
 +++ b/protocol/randr.xml
 @@ -0,0 +1,151 @@
 +?xml version=1.0 encoding=UTF-8?
 +protocol name=randr
 +
 +  copyright
 +Copyright © 2012-2013 Collabora, Ltd.

Fix this.

 +
 +Permission to use, copy, modify, distribute, and sell this
 +software and its documentation for any purpose is hereby granted
 +without fee, provided that the above copyright notice appear in
 +all copies and that both that copyright notice and this permission
 +notice appear in supporting documentation, and that the name of
 +the copyright holders not be used in advertising or publicity
 +pertaining to distribution of the software without specific,
 +written prior permission.  The copyright holders make no
 +representations about the suitability of this software for any
 +purpose.  It is provided as is without express or implied
 +warranty.
 +
 +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
 +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
 +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 +THIS SOFTWARE.
 +  /copyright
 +
 +  interface name=wl_randr version=1
 +description summary=randr
 +  The global interface exposing randr capabilities.
 +  As a wl_randr, that provides the interfaces for apps to more operations
 +  on output.
 +
 +  The aim of wl_randr is to get modes list, choose preferred mode,
 +  layout the output including position, rotate, and en/disable.
 +  The idea is from xrandr protocoal of xserver. It is very convenient for
 +  weston/wayland user to operates on mode setting of output.
 +/description
 +
 +enum name=error
 +  entry name=bad_randr value=0
 + summary=the to-be wl_randr is invalid/
 +/enum
 +
 +request name=destroy type=destructor
 +  description summary=unbind from the wl_randr interface
 + Informs the server that the client will not be using this
 + protocol object anymore. This does not affect any other
 + objects, wl_randr objects included.
 +  /description
 +/request
 +
 +request name=set_mode
 +  description summary=set the mode of output
 + set the mode of output
 +  /description
 +  arg name=output type=object interface=wl_output
 +   summary=the output object/
 +  arg name=width type=int/
 +  arg name=height type=int/
 +  arg name=refresh type=int/
 +/request

Since you require a wl_output, there does not seem to be a way to force
a disconnected output on? Should there be? Why else would you need a
way to list disconnected outputs?

Should there be a way to force a connected output off?

What about detailed mode timings? Should the client be allowed to use
e.g. CVT or GTF formulae to invent completely new modes that the
hardware might support?

 +
 +request name=set_transform
 +  description summary=set the transform of output
 + set the transform of output
 +  /description
 +  arg name=output type=object