Re: [PATCH i-g-t 04/10] tests/kms_cursor_crc: use CRTC indexes instead of pipes for CRTC tracking

[Jani Nikula <jani.nikula@intel.com>]

On Tue, 10 Mar 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Mon, Mar 09, 2026 at 04:21:38PM +0200, Jani Nikula wrote:
>> @@ -1286,8 +1286,8 @@ int igt_main_args("e", NULL, help_str, opt_handler, NULL)
>>  		igt_display_require_output(&data.display);
>>  		/* Get active pipes. */
>>  		for_each_crtc(&data.display, crtc)
>> -			active_pipes[last_pipe++] = crtc->pipe;
>> -		last_pipe--;
>> +			active_crtcs[last_crtc_index++] = crtc->crtc_index;
>> +		last_crtc_index--;
>
> It looks like when we get rid of the n_crtcs==MAX_PIPES mess
> all of these array things could just be nuked. But I suppose
> we're not quite there yet.

Yeah, we're close. At least one prerequisite is returning NULL from
igt_crtc_for_pipe() for non-existing pipes. After that, display->crtcs
could be just the valid CRTCs in pipe order. And then n_crtcs could be
shrunk to match valid CRTCs. And there are other possible cleanups after
that.

Of course, display->crtcs couldn't be indexed with pipe anymore, but
there are so few igt_crtc_for_pipe() users left that it shouldn't really
matter.

Also, I believe changing the order from pipe to CRTC index order might
be really hard to review. Probably not worth it, at least for now.

Once we've gotten rid of most of the crtc->pipe and enum pipe uses, I've
wondered if we shouldn't rename them crtc->vendor_pipe and enum
vendor_pipe or something along those lines, to emphasize folks should
probably steer clear for regular use.

BR,
Jani.


-- 
Jani Nikula, Intel