Re: Implementing Miracast?

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Jaakko,

On Thursday 03 December 2015 14:42:51 Hannikainen, Jaakko wrote:
> 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?

As you raise the issue, how would you prevent proprietary userspace drivers to 
be implemented ? Anything that would allow vendors to destroy the Linux 
graphics ecosystem would receive a big nack from me.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel