Do note that we're in the process of phasing out the policy manager from the windowmanager, but there's something that I'd like to point out, as maybe I might be missing something with it. Yes this will no longer be enabled, but I'd like to understand the old behaviour and the expectation and functionality of/for the new one. 

So I've built agl-cluster-demo-platform and ran that on the H3 board. The cluster-gauges  (presumably the dashboard) and the cluster-receiver are running. In the middle, between the gauges there's area where the remote streaming surfaces will be placed. 

The cluster-receiver is using "normal.full" as its area name, and is defined like:

{
 "name": "normal.full",
 "rect": {
 "x": 640,
 "y": 180,
 "w": 640,
 "h": 720
 }
 },

My understanding is that the x and y represent the start (origin) of that area and the width and height signify the area where to place the remote content. 

Now, the agl-weston-remoting will add up to the weston.ini config file the following: 

cat meta-agl-bsp/recipes-graphics/wayland/weston-ini-conf/remote-output.cfg 
[remote-output]
name=remote-1
mode=640x720@30
host=192.168.20.99
port=5005

Note that the area in the config file is exactly the same as the one defined in that area.json.

The area in question 640x720. 

I'm not really sure what this area really denotes: either a bounding box, or a area which the incoming remote surface should resize to. 

I've made a few experiments: 

1. From the compositor using a different mode, higher than the one in areas.json file, with 800x600 I see that the there's no resize happening but instead it seems that somehow it slightly moved, but indeed clipped to that area.
2. I've tried then modifying areas.json with the same value that it would be on the remote to have them matched. When I try to do that, the whole application (the cluster gauges I mean) will be clipped to that area. But not only that, but putting back the original values will not make any visible changes – once you modified areas.json those changes seem to be there until I generate a new image. Note that I've rebooted the machine each time I've operated changes on configuration files to make sure the changes do apply. Once you modify the geometry area there doesn't seem to be a way to put the "original" area back. I don't really understand how this happens. 

I'm going to attach some pictures of what I'm seeing to better exemplify. The first with the pink backgrounds shows the first use-case (where I have a remote output bigger than one specified in areas.json on the receiver side) and the second is after I put back the original values in areas.json. The first image has no transformation in the compositor, while the latter maintains the same weston.ini file, hence the 180 degree transformation of the output.

Anyway, more important question is: should the bounding box (I've added previously) be sufficient to achieve the same thing? Or should we resize the incoming surface to match the one defined? 

I don't have configuration for that, like windowmanager has, but we can modify the protocol and instead of the bounding box, we can try to resize to the values specified. 

For the moment I'm going try out the converted version of the dashboard and the bounding box so see how that works. 

CC scottm jsmoeller feed-back is really welcome so I can start pushing some changes if needed.