Implementing Miracast?

[Hannikainen, Jaakko]

Hello,

We're developing Miracast (HDMI over Wireless connections). The current
progress is that it 'works' in the userspace but doesn't have any
integration with X/Wayland and can only mirror the current desktop
using gstreamer.

We're looking into extending the implementation so that we would be
able to use the remote screens just as any other connected screen, but
we're not quite sure where we should implement it.

The DRM interface seems like the perfect fit since we wouldn't need to
patch every compositor.

Right now, gstreamer is the equivalent of the crtc/encoder, in the DRM
model. Screens / crtcs are discovered using a WiFi's p2p protocol which
means that screens should be hotpluggable. Since we cannot change the
number of crtcs of a driver on the fly, we propose adding and removing
gpus with one crtc attached and no rendering capabilities.

Compositors and X currently use udev to list gpus and get run-time
events for gpu hot-plugging (see the work from Dave Airlie for USB
GPUs, using the modesetting X driver). We did not find a way to tell
udev that we have a new device and it seems like the only way to get it
to pick up our driver is from a uevent which can only be generated from
the kernel.

Since we have so many userspace components, it doesn't make sense to
implement the entire driver in the kernel.

We would thus need to have a communication from the kernel space to the
userspace at least to send the flip commands to the fake crtc. Since we
need this, why not implement everything in the userspace and just
redirect the ioctls to the userspace driver?

This is exactly what fuse / cuse [1] does, with the minor catch that it
creates devices in /sys/class/cuse instead of drm. This prevents the
wayland compositors and X to pick it up as a normal drm driver...

We would thus need to have the drm subsystem create the device nodes
for us when the userspace needs to create a new gpu. We could create a
node named /dev/dri/cuse_card that, when opened, would allocate a node
(/dev/dri/cardX) and would use cuse/fuse to redirect the ioctls to the
process who opened /dev/dri/cuse_card.

The process would then be responsible for decoding the ioctl and
implementing the drm API.

Since this is a major change which would allow proprietary drivers to
be implemented in the userspace and since we may have missed something
obvious, we would like to start a discussion on this. What are your
thoughts?

[1] https://lwn.net/Articles/308445/