Possible inconsistencies in the policy manager from windowmanager

Description

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:

 

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: 

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  feed-back is really welcome so I can start pushing some changes if needed. 

 

 

Environment

None

Attachments

2

Activity

Show:

Marius Vlad 
July 29, 2020 at 9:13 PM

Given that we're no longer use this, this was more an informative question(s). We can focus/address them directly with the agl-compositor. 

Marius Vlad 
June 29, 2020 at 1:43 PM
(edited)

Hi,

Thanks for the reply, but I'm a bit confused.

You said "source rectangle (in this case, wayland-sink's 800x600 surface) should be resized to destination rectangle (640x720), but as far as I know, there are not any expectations nor requirements for this resizing."

I gather that resizing would be nice to have, but there's *no strict* requirement for it.

Tadao Tanikawa 
June 23, 2020 at 2:25 PM

As far as I know, resizing by compositor is not necessary.  Remote mechanism is following,

  1. MapView draw contents with 640x720 on remote-ouput of  ivi's weston. 

  2. IVI-Cluster remoting transfer whole remote-output to receiver app on cluster demo by H264 video stream.

  3. The receiver decodes video using GStreamer with wayland-sink, so that surface would be created with 640x720

  4. WM layout receiver surface to x=640, y=180, w=640, h=720

  5. Then, contents will be shown without resizing

If you change the size of remote-ouput (e.g. 800x600), then receiver would receive 800x600 video stream and gstreamer wayland-sink would create surface with 800x600.

From ivi-shell (which is old window manager using) point of view, source rectangle (in this case, wayland-sink's 800x600 surface) should be resized to destination rectangle (640x720), but as far as I know, there are not any expectations nor requirements for this resizing.

However, it seems that resize is not working properly, probably due to a bug in WM

 

Walt Miner 
June 23, 2020 at 1:31 PM
(edited)

any comments on this issue?

Scott Murray 
June 19, 2020 at 3:09 PM

I don't have a strong opinion.  Someone more involved in the design of the old windowmanager like , , or someone from ADIT or Toyota will need to comment on what the expected behavior was and should be.

Fixed

Details

Assignee

Reporter

Priority

Created June 19, 2020 at 10:21 AM
Updated August 21, 2020 at 3:46 PM
Resolved July 29, 2020 at 9:13 PM