在 2026-05-22五的 15:43 +0200，Thomas Zimmermann写道： > Hi > > Am 22.05.26 um 15:28 schrieb Ville Syrjälä: > [...] > > > > > But why does your HW use CRTC 1 in the first place. > > > > Could be eg. the enabled outputs can't be driven with CRTC 0.
Yes, for many embedded display solutions the CRTC-connector map is totally fixed. > > > > > > > > I guess what you want to do is pick the first crtc from > > > > modesets[] > > > > which is enabled. Or perhaps even "pick the Nth enabled crtc > > > > from > > > > modesets[] based on the ioctl argument". > > > The enable-status of each CRTC could change later on, which might > > > lead > > > to problems. > > Sound like a locking issue if someone is changing the configuration > > at the same time we're trying to do the vblank wait here. > > I mean that the connected outputs could change at a later point or we > could have multiple CRTCs in use. Today, someone in #intel-gfx > reported > a problem with panning if multiple CRTCs are in use. > > Therefore picking a CRTC freely could be a problem. Let's say we > configure modes from one CRTC, but later wait/pan/flush with another > CRTC. I would not trust this to work correctly. > > Hence, my suggestion is to select a primary CRTC during the fbdev > client's probe and use it for all later operations until the next > probe > happens. All other CRTCs would mirror the primary one. What will happen if the "primary CRTC" is then disabled because of no connected connectors can be driven with it? Thanks, Icenowy > > Best regards > Thomas > > > > > > > Picking the one CRTC/output with the lowest spec and > > > mirroring it to the others might work. This CRTC would then be > > > the one > > > to wait for. > > > > > > Best regards > > > Thomas > > > > > > -- > > > -- > > > Thomas Zimmermann > > > Graphics Driver Developer > > > SUSE Software Solutions Germany GmbH > > > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > > > GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, > > > AG Nürnberg) > > >
