Hi
On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres martin.peres@free.fr wrote:
On 08/12/15 13:59, David Herrmann wrote:
I looked into all this when working on WFD, but I cannot recommend going down that road. First of all, you still need heavy modifications for gnome-shell, kwin, and friends, as neither of them supports seamless drm-device hotplugging.
That would still be needed for USB GPUs though. Seems like metacity had no probs in 2011, but no idea how heavily patched it was: https://www.youtube.com/watch?v=g54y80blzRU
Airlied?
Yes, Xorg has offload-sinks. But if you target Xorg, then you can just as well implement user-space sinks in Xorg, and you're done. But given that you talk about "compositors" here, I assume you're targeting wayland compositors. Otherwise, there is really nothing to implement in Gnome and friends to make external displays work. Supporting it in Xorg would be enough.
Long story short: offload-sinks like UDL only work properly if you use Xorg (if my information is outdated, please correct me, but I haven't seen any multi-display-controller-support in clutter or kwin or even weston).
Hence, providing more devices than the main GPU just confuses them. Secondly, you really don't win much by re-using DRM for all that. On the contrary, you get very heavy overhead, need to feed all this through limited ioctl interfaces, and fake DRM crtcs/encoders/connectors, when all you really have is an mpeg stream.
The overhead is just at init time, is that really relevant? The only added cost could then be the page flip ioctl which is not really relevant again since it is only up to 60 times per second in usual monitors.
This is not so much about overhead, but API constraints. Putting stuff into the kernel just places arbitrary constraints on your implementation, when you don't have any real gain.
I wouldn't mind if anyone writes a virtual DRM interface, it'd be really great for automated testing. However, if you want your wifi-display (or whatever else) integrated into desktop environments, then I recommend teaching those environments to accept gstreamer sinks as outputs.
That is a fair proposal but that requires a lot more work for compositors than waiting for drm udev events and reusing all the existing infrastructure for DRM to drive the new type of display.
This is not true. Again, I haven't seen any multi-display-support in any major compositors but Xorg (and even for Xorg I'm not entirely sure they support _fully_ independent display drivers, but airlied should know more).
I guess there are benefits to being able to output to a gstreamer backend, but the drm driver we propose could do just that without having to ask for a lot of new code, especially code that is already necessary for handling USB GPUs. Moreover, the gstreamer backend would not be registered as a screen by X which means that games may not be able to set themselves fullscreen on this screen only.
I am open to the idea of having compositors render to a gstreamer backend, but I never worked with gstreamer myself so I have no clue about how suited it is for output management (resolution, refresh rate) and there is the added difficulty of the X model not working well with this approach. We will have a look at this though.
As I said earlier, I'm not opposed to a virtual DRM driver. I'm just saying that you should not expect it to work out-of-the-box in any major compositor. I spent a significant amount of time hacking on it, and my recommendation is to instead do all that in user-space. It'll be less work.
Thanks David