On Mon, Sep 8, 2014 at 8:43 PM, Dave Airlie <airlied@xxxxxxxxx> wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connected
>
> hotplug 30" monitor, userspace decides to configure things as
>
> CRTC 1: DP-4 - 30" monitor
> CRTC 2: eDP-1
>
> But since we lack atomic it does this in two steps, so when I get the
> first modeset to set the 30" monitor up
> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> then I have to fail the second modeset,
> and things end up with me crying.
>
> So this led me to wonder why we expose CRTCs at all, and KMS does it
> because randr did it, but I've no idea
> why randr did it (Keith??).
>
> From my POV I don't think the modesetting interface needs to take
> crtcs, just connectors and modes,
> so I'm wondering going forward for atomic should we even accept crtcs
> in the interface, just a list of rectangles,
> connectors per rectangle, etc.
>
> Now I'm at the point of trying to work out if I can make DP MST
> monitors a possibility before we get atomic,
>
> Myself and Ben discussed this here and he suggested we should make the
> userspace crtc ids pretty much
> meaningless and not have them tied to actual hw crtcs, so we can
> reroute things underneath userspace
> without changing it.
>
> Any input is welcome!
What about exposing monitors as a modesetting object? They could have
a required_crtc_num attribute or something like that. I guess it's a
little late since we already did dynamic connectors for MST and I
guess it would be complicated to integrate cleanly with the way we do
things today.
E.g., you could have:
crtc -> encoder -> connector -> monitor
or
crtc - -> monitor
\ /
crtc - --> encoder -> connector -> monitor
/ \
crtc - -> monitor
or
crtc -
\
crtc - --> encoder -> connector -> monitor
etc.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
