Hello, I'm looking for ideas and suggestions on how to enable IGT to work on planes with multiple possible_crtcs during atomic commit. Amdgpu currently has features that rely on this, and planes with multiple crtc's are not being properly committed when tests run an atomic commit. To explain, DRM has a field on planes called "possible_crtcs" that allows a plane to be valid for multiple CRTC's. In igt_display_init(), it is used to determine whether a igt_plane should be attached to a pipe. Therefore, when a plane specifies a possible_crtcs of say, 0xFF, igt_display_init() will create *copies* of this plane and attach it to all available pipes. The problem arises when committing changes via igt_atomic_commit (which eventually calls drmModeAtomicCommit). Say we have two pipes (A and B) and a single plane with possible_crtcs=0xFF. igt_display_init() will create copies of this plane and store it within both A and B, as 0xFF makes it a valid plane for both pipes. Keyword here is "copies", since a change to A.plane will not be reflected in B.plane. For example, say we call igt_plane_set_fb() using A.plane, changing its fb_id. After this call, A.plane.fb_id will be updated, and B.plane.fb_id will remain stale. We then call igt_atomic_commit() to commit the fb changes. When preparing the set of properties to commit, the updated fb_id from pipe A will first be set, followed by the stale fb_id from pipe B. DRM then removes duplicates from the property set before calling the atomic commit ioctl. Since the algorithm keeps the duplicate item with the largest index, the update to A.plane gets overridden by B.plane's stale fb_id property, causing unexpected behavior. One possible solution is to have igt_pipe_t use an array of pointers to igt_plane_t, and have the set of unique igt_plane_t's stored elsewhere (perhaps under igt_display_t). Changes to A.plane will then be properly reflected on B.plane since it is by reference. However, igt_display_init() will have to be modified, and igt_plane_t's pipe and index fields will have a different meaning. Another possibility is to introduce a field within igt_plane_t to reference the "one true copy". Any read or write to the plane's fields will then have to first check if it is a copy, and reference the one true copy in the event that it is. This can get quite messy. The modifications seem to be quite wide, and I'd like some input on this before I jump in. Any ideas and/or suggestions will be very much appreciated! Thanks, Leo
