Hi All,
Please find below a brief summary of the progress Collabora have made last week on Weston/Wayland.
Weston / Wayland
Marius:
- further validation of the topic branch integration for
agl-compositor (removal
of -*windowmanager packages) and conversion of remaing apps.
So far, testing it
in a virtualized environment until I have a working version
for the H3 board (BSP integration
is in the works for).
Remote display of windows/applications:
- initial conversion of tbtnavi application, which I've used
to test out window/application
placement on other outputs.
- testing out xdg_output/qtwayland display of human-like
representation of the output such that
we can make use of it when applications want to be displayed
on other outputs. Application parse
the list of available outputs and choose the output they want
to be displayed on. Windowmanager was
abstracting the remote output, by making of use of layer
specially created (assigned on other outputs).
This required the usage of configuration files to decide which
application can be transferred
to that layer. As we no longer make use of that, we allow
applications to make dynamic decisions based
on their environment without the need to further modify
compositor configuration files.
The policy engine is the one making the decisions if
constrainment is necessary.
- added and implemented a 'remote' role for the surface, that
acts (like the other surface roles: split or
pop-up) as a hint for the compositor to make further necessary
adjustments. Protocol explicitly demands
an output but this was (still) necessary to display the
surface once the application has started (a feature
that we call display_by_default). Note that both the
activation request and the surface role assingment
request explicity requires an output, which allows dynamic
surface placement for free, without further
manipulation of configuration files, nor require compositor
modification.
- Modified tbtnavi to make use of the 'remote' surface role.
- Policy engine designers can check the surface type and the
output it is being used to display the surface
in order to restrict/refuse placement of the surface on that
respective output
- The above are, for the moment, under review to determine
which is the best course of action, the alternative
being to use some sort of a tagging mechanism based on
application-type roles, similarily to what the
windowmanager had previously.
Things currently looking into:
- SPEC-3280 - Remote-display/placing sufrace IDs over to other
outputs, looking into testing out some
corner cases, especially the interfaction between setting window
properties with the 'remote' surface role and the
activation request
- SPEC-3386 - Improve documentation (useful in explaining some of
the protocol and internal design as to
provide better explanations for further design implementation)
Things to do in queue:
- SPEC-3382 Investigation of cluster demo image w/ tweaked area
and role configuration for
the windowmanager
- input focus for background/regular applications, added SPEC-3344
for tracking
Kind regards,
Nick
Links:
You receive all messages sent to this group.
View/Reply Online (#8371) |
Reply To Group
| Reply To Sender
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[list-automotive-discussions82@xxxxxxxxxxx]
