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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
