[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:ppaalanen at gmail.com] 
Sent: Wednesday, March 05, 2014 4:48 PM
To: Wang, Quanxian
Cc: Jasper St. Pierre; Jason Ekstrand; Hardening; Matthias Clasen; wayland-devel at 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 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> 
> 
> From: wayland-devel-bounces at lists.freedesktop.org
> [mailto:wayland-devel-bounces at 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 at 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 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.

The hardware driver may offer several video modes just because it is using standard drivers and components which just happen to support multiple video modes out of the box. It would take more effort to not expose them.

Then again, the compositor could just not expose them, in which case the whole configuration protocol would be useless.

To me it seems that the goal, the use cases, and the target audience of this proposal are still up in the air. I think you should re-think the questions I gave you:
- Would you be happy with something that works for your specific use
  case only?
- Do you want to establish a universal standard, i.e. get this into
  Wayland core? If so, why?
- Do you want a sample implementation and the protocol be included in
  Weston specifically? If so, why?

The foremost, what is the use case?

"Because someone might want to change the video mode at runtime" is not a use case, and I don't think we have yet heard a good reason why anyone would want to do that in the way that you have proposed. That is, why would anyone want to use the xrandr-command?

For example, if you meant this for desktop environments so that they can implement their output management GUIs, you should first find out if they actually need it, or if they already have a solution.

Once you are clear on the "what" and "why", we can help you with the technical "how".

FWIW, I could see some value in dynamic configuration of Weston, the same way as xrandr is used, to easily try new video mode settings before writing them into the server configuration file for permanent use. That would make it specific to Weston, and have fairly different requirements to what we have been talking here. Trying new settings to find a good one is very different to allowing a client do modesetting at will. E.g. one thing that xrandr lacks AFAIK is a way to show what you should write into the server config file to achieve the current output setup.

On Wed, 5 Mar 2014 06:02:45 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

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

Yeah, ok, but *why* would anyone use that if not only for testing new output configurations?


Thanks,
pq