Re: Implementing Miracast?

From: Martin Peres <martin.peres@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: Implementing Miracast?
Date: Fri, 4 Dec 2015 15:22:13 +0200	[thread overview]
Message-ID: <56619385.8040608@linux.intel.com> (raw)
In-Reply-To: <20151204080729.GV10243@phenom.ffwll.local>

On 04/12/15 10:07, Daniel Vetter wrote:
>
> Hm for virtual devices like this I figured there's no point exporting the
> full kms api to userspace, but instead we'd just need a simple kms driver
> with just 1 crtc and 1 connector per drm_device.

Yes, we do not need anything more. But don't forget the requirement that 
we should be able to hotplug new gpus when new screens become available 
(there may be more than one). We thus need to create a node that when 
opened, would create a "screen" node that will be seen as a normal gpu 
by X and wayland compositors (cardX?). One userspace process will likely 
control all the miracast screens.

> Plus a special device
> node (v4l is probably inappropriate since it doesn't do damage) where the
> miracast userspace can receive events with just the following information:

Not sure it is a good idea as it would force compositors to learn about 
miracast, which is not necessary.

> - virtual screen size
> - fd to the underlying shmem node for the current fb. Or maybe a dma-buf
>    (but then we'd need the dma-buf mmap stuff to land first).

Darn it, I was sure this had already landed. I guess it is OK as long as 
we expose a GEM interface that would allow us to import the dma-buf into 
a GEM buffer which we would then mmap through the usual API. Buffer 
allocation is not necessary though.

> - damage tracking
>
> If we want fancy, we could allow userspace to reply (through an ioctl)
> when it's done reading the previous image, which the kernel could then
> forward as vblank complete events.

Sounds good :)

>
> Connector configuration could be done by forcing the outputs (we'll send
> out uevents nowadays for that), so the only thing we need is some configfs
> to instantiate new copies of this.

Are you suggesting hotplugging connectors instead of GPUs? Not sure if 
compositors will like that :s

>
> At least for miracst (as opposed to full-blown hw drivers in userspace) I
> don't think we need to export everything.

We indeed do not need to export anything related to rendering!

> Cheers, Daniel
>

Thanks for your feedback Daniel!

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