On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie 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. > > Not all CRTCs are created equal so the user probably wants know what > features to expect from a particular CRTC. Now, often that may have > something to do with the planes, but there are other hardware features > that we want to expose as CRTC properties. If we make all CRTCs appear > uniform to userspace the user may not know beforehand that certain > features can only be used on a subset of CRTCs. Also if the driver > would initially pick the wrong CRTC, and later the user would enable > one of those special features, we'd have to do a full modeset to switch > hardware CRTCs which would mean a nasty screen blink for the user. first off, I tend to think with the trend towards various different wayland compositors doing kms directly, making it easier for userspace sounds pretty attractive. Ie. would you rather fix a bug w/ picking the right crtc for the job in N compositors, or 1 kernel driver? But that said, it seems like the real problem w/ kernel picking the right crtc is going to be with non-atomic modeset. And for pre-atomic (future legacy) xrandr, I'm not entirely sure how userspace is supposed to do a better job at this than the kernel could. It would also need up front knowledge of all the modes that would be picked. So you've just pushed non-atomic suck in the kernel to non-atomic suck in x11. Doesn't sound like that fixes anything. But, I think there is maybe a way to have our cake and eat it too.. to leave extra flexibility for highly customized/specialized userspace, we could just allow for some PICK_ANY_CRTC_FOR_ME type value which would let 99% of userspace push the decision to the kernel, while still allowing for the special cases where userspace knows better. BR, -R > So no, I don't think this is a good idea given real world hardware > constraints. > > -- > Ville Syrjälä > Intel OTC > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
