Hi All,
Please find below a brief summary of the progress Collabora have made last week on Pipewire and Weston/Wayland.
Week 9 2020
PipeWire
George:
- Merged Julian's fade in/out support branch in wireplumber;
note that upstream support in pipewire has not been merged
yet
- Reviewed and merged Julian's unit test fixes
- Started designing a more flexible API for implementing
session management functionality
associated with endpoints and streams. This will allow
reusing parts of the current
audio endpoint pipeline, which was created specifically to
target AGL's needs, to
create pipelines that target desktop and other use cases. At
the same time, this API
should make it easier to implement new components in the
future.
Julian:
- Fixed hanging issues in wireplumber unit tests by running
the main loop in the same
thread as the unit tests.
- Fixed small wireplumber issues when running JACK audio
clients, and created MR.
- Started implementing WpVideoEndpoint sub-class to handle
video clients in wireplumber.
Weston / Wayland
Daniel:
Marius:
- back-merge of next into master still revealed some build
failures. Most of them
seem to have a fix (still pending for merging). A couple of
them where closer to my
part: WAM gcc update and chromium68 build failure. Helped in
testing some of the fixes.
All of the them have Jira items associated.
- Related to WAM: turns out that chromium68 does not expose
wayland primitive that
allow binding the agl-shell protocol interface (we normally
piggy-back on the wayland
connection and use that to retrieve the registry and bind to
the interface). Had an
attempt to expose it but proved that it ain't sufficient and
wasn't successful in
using it (thought it looked it could've have worked -- seems
to be related to
namespacing/bulding but not really sure at this stage).
Reached out to Igalia to help out a bit with it or provide
some assistance. Still
waiting for more feedback on this side. Initial suggestion
(from Igalia) was to
provide an abstraction layer in chromium68 and expose it that
into WAM. While this
seems alright for upstreaming purposes it is a rather big
detour and I'd have liked
to advance a bit in WAM to see what else might be needed (for
homescreen at least we need
a way to pass the a surface back from chromium68, for
instance). I'm still waiting
here to get more information, then I'll see how to proceed.
- Related to policy-manger: Due to build failures and WAM
hold-up for the moment,
started to prototype a policy API which should allow adding
hooks in the compositor
but also provide the means to inject events/states back in
the compositor.
Half way through at this point. Looking into testing it.
Kind regards,
Nick
Links:
You receive all messages sent to this group.
View/Reply Online (#8125) |
Reply To Group
| Reply To Sender
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[list-automotive-discussions82@xxxxxxxxxxx]
