Binding sources to multiple pipelines
Is it possible to bind a single WFDSource to multiple pipelines simultaneously?
The use case I'm thinking of is splitting a single desktop across two displays/monitors. To easily be able to drag windows between monitors, there would be a single source image large enough to cover both bits of display hardware. This source image would then be connected to two pipelines, one for each port (with one monitor connected to each port). Each of those pipelines would have a different WFD_PIPELINE_SOURCE_RECTANGLE.
This is all obvious how to do from the OpenWF Display specification. However, I can't seem to find any reference in the spec which says you can bind a single WFDSource to multiple pipelines simultaneously. It's also not a requirement for the above use case: Instead of creating a single WFDSource, you could create two WFDSources from the same EGLImage or even create two sibling EGLImages and create a WFDSource out of each.
Any clarification (or RTFM referencing part of the spec I've missed :) ) would be greatly appreciated.
Re: Binding sources to multiple pipelines
The UI split across two monitors use case was considered during development of the WFD spec. I believe after sometime it was decided that the implementation of the use case was going to be up to the WFD client, which seems to be your target, so that's good.
I don't believe there should be anything stopping you from performing the use case as you described it using EGLImages. The WFD Pipeline Sources were created as wrappers around the pipeline input mostly to allow for all the sanity checking on the input to be done once at source creation time instead of at bind time. Also, the source wrapper places a reference on the input object to ensure it does not get destroyed while it's being used. The use of native streams in this use case is not clear to me. It may very well be possible depending on the native stream, but streams are not my strength, I'll have to see if I can find someone else to help on on that front.
Concerning your comment that there are not any clear statements in the spec defining if this is possible or not, I agree there isn't and there probably should be. We see what we can do to resolve this in the next release.