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.com<mailto:ppaala...@gmail.com>> wrote:
>
> On Wed, 5 Mar 2014 09:24:34 +0000
> "Wang, Quanxian" <quanxian.w...@intel.com<mailto: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 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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to