Implementing Miracast?

[David Herrmann]

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.

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).

>> Hence, providing more devices than
>> the main GPU just confuses them. Secondly, you really don't win much
>> by re-using DRM for all that. On the contrary, you get very heavy
>> overhead, need to feed all this through limited ioctl interfaces, and
>> fake DRM crtcs/encoders/connectors, when all you really have is an
>> mpeg stream.
>
> The overhead is just at init time, is that really relevant? The only added
> cost
> could then be the page flip ioctl which is not really relevant again since
> it is only up
> to 60 times per second in usual monitors.

This is not so much about overhead, but API constraints. Putting stuff
into the kernel just places arbitrary constraints on your
implementation, when you don't have any real gain.

>> I wouldn't mind if anyone writes a virtual DRM interface, it'd be
>> really great for automated testing. However, if you want your
>> wifi-display (or whatever else) integrated into desktop environments,
>> then I recommend teaching those environments to accept gstreamer sinks
>> as outputs.
>
>
> 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).

> 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.

Thanks
David