Re: Implementing Miracast?

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

Hi Ilia,

On Thursday 03 December 2015 11:03:28 Ilia Mirkin wrote:
> On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote:
> > On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote:
> >> On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart wrote:
> >>> 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.
> >> 
> >> AFAIK the displaylink people already have precisely such a driver -- a
> >> (open-source) kernel module that allows their (closed-source)
> >> userspace blob to present a drm node to pass through modesetting/etc
> >> ioctl's.
> > 
> > Are you talking about the drivers/gpu/drm/udl/ driver ? I might be wrong
> > but I'm not aware of that kernel driver requiring a closed-source
> > userspace blob.
> Nope. That driver only works for their USB2 parts. This is what I mean:
> 
> https://github.com/DisplayLink/evdi
> http://support.displaylink.com/knowledgebase/articles/679060
> http://support.displaylink.com/knowledgebase/articles/615714#ubuntu

Right. That's out-of-tree, people are free to screw up on their own there ;-)

-- 
Regards,

Laurent Pinchart

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