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? [1] https://lwn.net/Articles/308445/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
