On Thu, Nov 19, 2015 at 3:24 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Thu, Nov 19, 2015 at 03:02:09PM +0100, Daniel Vetter wrote: >> On Thu, Nov 19, 2015 at 12:12:28PM +0200, Ville Syrjälä wrote: >> > On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote: >> > > This was totally lost when I originally created the atomic helpers. >> > > >> > > We probably should also check possible_clones in the helpers, but >> > > since the legacy ones didn't do that this is for a separate patch. >> > > >> > > Reported-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > > Cc: Daniel Stone <daniels@xxxxxxxxxxxxx> >> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> >> > >> > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > Tested-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > >> > But the rest of update_connector_routing() still looks somewhat bonkers >> > to me. For one, it assumes that both the old and new crtc for the >> > connector are part of the atomic state, but drm_atomic_set_crtc_for_connector() >> > only adds the new crtc, not the old one. >> >> Nothing bonkers about it since drm_atomic_get_connector_state ensures that >> the corresponding crtc state is part of the update. Same logic applies for >> planes. > > Ah, that's where it was. OK, so it's just seems bonkers in other ways ;) > > Let's say we have as a starting point: > crtc0 -> enc0 -> conn0 > crtc1 -> enc1 -> conn1 > > Then we do an atomic_ioctl() > -> set conn0 -> NULL > -> set conn1 -> crtc0 > -> set conn2 -> crtc1 > > And if enc1 is the best_encoder for both conn1 and conn2, > it looks to me like we would silently end up with just: > crtc1 -> enc1 -> conn2 > > Even though the user asked for: > crtc0 -> conn1 > crtc1 -> conn2 Yeah this is what will happen, since perfect backwards compat to old Vjuserspace. We could fix this (probably by outright disabling encoder stealing), but I'm not too concerned really: Practically it's impossible to ask for this config (since you can't plug in both HDMI and DP). Same holds for other drivers, where encoder routing is at most used to select between dvi and crt encoders for DVI-I/D. > Also the code seems to assume that a single encoder can't drive multiple > connectors at once. Is that by design or an accident? That's by design - the cloning mask it as the encoder level, so hw cloning happens between crtc/encders. > So I'm thinking maybe we should first check for routing conflicts in the > new state and fail if any were found. After that we could go through the > old state to steal stuff, and we should disallow stealing for the atomic > ioctl totally and only allow if from setcrtc. Otoh I guess we could do that too, just for consistency. Simples approach would be a bool in connector_state which we leave at false in duplicate_state. Then on the first set_crtc_for_connector we set it to true and refuse to steal from such connectors. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
