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. 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
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
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
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
[PATCH] shell: position input panel layer above fullscreen layer
When a client calls the input panel (weston-keyboard e.g.)
and then goes fullscreen, the panel will not be hidden
anymore.
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
desktop-shell/input-panel.c |2 +-
desktop-shell/shell.c | 17 +
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index c08a403..12fe686 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -63,7 +63,7 @@ show_input_panels(struct wl_listener *listener, void *data)
shell-showing_input_panels = true;
if (!shell-locked)
- wl_list_insert(shell-panel_layer.link,
+ wl_list_insert(shell-compositor-cursor_layer.link,
shell-input_panel_layer.link);
wl_list_for_each_safe(ipsurf, next,
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fd9ead0..09d1914 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -72,9 +72,9 @@ enum shell_surface_type {
* in the following order (top-most first):
* • Lock layer (only ever displayed on its own)
* • Cursor layer
+ * • Input panel layer
* • Fullscreen layer
* • Panel layer
- * • Input panel layer
* • Workspace layers
* • Background layer
*
@@ -3794,18 +3794,19 @@ resume_desktop(struct desktop_shell *shell)
terminate_screensaver(shell);
wl_list_remove(shell-lock_layer.link);
- wl_list_insert(shell-compositor-cursor_layer.link,
- shell-fullscreen_layer.link);
- wl_list_insert(shell-fullscreen_layer.link,
- shell-panel_layer.link);
if (shell-showing_input_panels) {
- wl_list_insert(shell-panel_layer.link,
+ wl_list_insert(shell-compositor-cursor_layer.link,
shell-input_panel_layer.link);
wl_list_insert(shell-input_panel_layer.link,
- ws-layer.link);
+ shell-fullscreen_layer.link);
} else {
- wl_list_insert(shell-panel_layer.link, ws-layer.link);
+ wl_list_insert(shell-compositor-cursor_layer.link,
+ shell-fullscreen_layer.link);
}
+ wl_list_insert(shell-fullscreen_layer.link,
+ shell-panel_layer.link);
+ wl_list_insert(shell-panel_layer.link,
+ ws-layer.link),
restore_focus_state(shell, get_current_workspace(shell));
--
1.7.10.4
___
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
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
-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
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 in
RE: [PATCH 1/6] Add weston randr protocol
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
