[PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

From: wayland-devel-bounces at lists.freedesktop.org [mailto:wayland-devel-bounces at 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 at 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" <ppaalanen at gmail.com<mailto:ppaalanen at gmail.com>> wrote:
>
> On Wed, 5 Mar 2014 09:24:34 +0000
> "Wang, Quanxian" <quanxian.wang at intel.com<mailto: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.

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 implementation could be exactly the same.

[Wang, Quanxian] Thanks for your information.

I hope that helps.
Thanks,
--Jason Ekstrand

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140306/cdaf0488/attachment-0001.html>