Implementing Miracast?

[Martin Peres]

On 08/12/15 19:24, David Herrmann wrote:
> Hi
>
> On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres <martin.peres at free.fr> wrote:
>> On 08/12/15 13:59, David Herrmann wrote:
>>> I looked into all this when working on WFD, but I cannot recommend
>>> going down that road. First of all, you still need heavy modifications
>>> for gnome-shell, kwin, and friends, as neither of them supports
>>> seamless drm-device hotplugging.
>>
>>
>> That would still be needed for USB GPUs though. Seems like metacity had no
>> probs
>> in 2011, but no idea how heavily patched it was:
>> https://www.youtube.com/watch?v=g54y80blzRU
>>
>> Airlied?
>
> Yes, Xorg has offload-sinks. But if you target Xorg, then you can just
> as well implement user-space sinks in Xorg, and you're done. But given
> that you talk about "compositors" here, I assume you're targeting
> wayland compositors. Otherwise, there is really nothing to implement
> in Gnome and friends to make external displays work. Supporting it in
> Xorg would be enough.

We would like to have a solution that works for as many display systems 
as possible, X and Wayland are of course the main goal. Surface flinger 
support would be nice too but no idea how it works.

So, we tested the following case, 3 GPUs (Intel, Nouveau, Nouveau), 3 
screens each connected to a different GPU. Screen 0 uses Intel.
Then we ran:
xrandr --setprovideroutputsource 1 Intel
xrandr --setprovideroutputsource 2 Intel

And got the 3 screens exposed by screen 0. xrandr --auto then did 
exactly what it is supposed to do. So, for the X case, there is nothing 
else to do than run the setprovideroutputsource xrandr command to add 
the new miracast screen, after creating the node.

Now that I think of it, we did not try with the modesetting driver but 
we could always add support for it.

>
> Long story short: offload-sinks like UDL only work properly if you use
> Xorg (if my information is outdated, please correct me, but I haven't
> seen any multi-display-controller-support in clutter or kwin or even
> weston).

They will have to be fixed at some point if they want to support USB 
GPUs and Optimus (and miracast?). So, why require them to add specific 
code for Miracast?

Dave, what did you do to make it work automatically on metacity?

>
>> That is a fair proposal but that requires a lot more work for compositors
>> than
>> waiting for drm udev events and reusing all the existing infrastructure for
>> DRM
>> to drive the new type of display.
>
> This is not true. Again, I haven't seen any multi-display-support in
> any major compositors but Xorg (and even for Xorg I'm not entirely
> sure they support _fully_ independent display drivers, but airlied
> should know more).

Sounds about right, but as we said before, there are other important 
cases, Optimus being the most important one, that require this support. 
So, why not ride on this for the less-than-usual case which is Miracast?

>
>> I guess there are benefits to being able to output to a gstreamer backend,
>> but
>> the drm driver we propose could do just that without having to ask for a lot
>> of
>> new code, especially code that is already necessary for handling USB GPUs.
>> Moreover, the gstreamer backend would not be registered as a screen by X
>> which
>> means that games may not be able to set themselves fullscreen on this screen
>> only.
>>
>> I am open to the idea of having compositors render to a gstreamer backend,
>> but
>> I never worked with gstreamer myself so I have no clue about how suited it
>> is for
>> output management (resolution, refresh rate) and there is the added
>> difficulty of
>> the X model not working well with this approach. We will have a look at this
>> though.
>
> As I said earlier, I'm not opposed to a virtual DRM driver. I'm just
> saying that you should not expect it to work out-of-the-box in any
> major compositor. I spent a significant amount of time hacking on it,
> and my recommendation is to instead do all that in user-space. It'll
> be less work.

Yes, you are right, it will require changes for the non-X case.

Since you spent a lot of time on it, could you share with us some of the 
issues you found? We still think that using the DRM interface may be 
more work, but at least it would improve the state of the graphics stack.

Thanks,

Jaakko and Martin