On 08/12/15 19:24, David Herrmann wrote:
Hi
On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres <martin.peres@xxxxxxx> 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.
We would like to have a solution that works for as many display systems
as possible, X and Wayland are of course the main goal. Surface flinger
support would be nice too but no idea how it works.
So, we tested the following case, 3 GPUs (Intel, Nouveau, Nouveau), 3
screens each connected to a different GPU. Screen 0 uses Intel.
Then we ran:
xrandr --setprovideroutputsource 1 Intel
xrandr --setprovideroutputsource 2 Intel
And got the 3 screens exposed by screen 0. xrandr --auto then did
exactly what it is supposed to do. So, for the X case, there is nothing
else to do than run the setprovideroutputsource xrandr command to add
the new miracast screen, after creating the node.
Now that I think of it, we did not try with the modesetting driver but
we could always add support for it.
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).
They will have to be fixed at some point if they want to support USB
GPUs and Optimus (and miracast?). So, why require them to add specific
code for Miracast?
Dave, what did you do to make it work automatically on metacity?
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).
Sounds about right, but as we said before, there are other important
cases, Optimus being the most important one, that require this support.
So, why not ride on this for the less-than-usual case which is Miracast?
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.
Yes, you are right, it will require changes for the non-X case.
Since you spent a lot of time on it, could you share with us some of the
issues you found? We still think that using the DRM interface may be
more work, but at least it would improve the state of the graphics stack.
Thanks,
Jaakko and Martin
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
