Hi Jaakko, 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. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
