[PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Wed, 5 Mar 2014 09:24:34 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> Hi, Jasper & Jason
> 
> In order to understand it more, I provide such cases.
> 
> 
> 1)       One customer uses handset which OS using wayland. When he
> open the handset, there is the menu screen which contain icons list.
> Someone want to see 10 icons, someone wants to see 20 icons. (one
> requirement, it really happens, at least when use my handset, I like
> to see everything in one page or more). Surface mode set is one way,
> output mode set is another way, apps setting is also another way(font
> size or icon size).

Runtime video mode switching in a phone? Is that even a thing? I mean,
does the hardware even support anything but a single video mode for
the panel?

As for the UI size, that is much better handled at the drawing phase in
applications, rather than by the scanout hardware doing scaling.

> 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