Implementing Miracast?
Martin Peres
martin.peres at linux.intel.com
Fri Dec 4 05:22:13 PST 2015
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
More information about the dri-devel
mailing list