[PATCH v2 0/6] drm/omap: Module parameter for display order configuration

[Tomi Valkeinen]

On 29/05/18 09:42, Daniel Vetter wrote:

> Thus far the rules has been that we try to put the integrated panel first,
> and that's it. See drm_helper_move_panel_connectors_to_head(). If there's

Ok. But we may also have multiple integrated panels.

> any standard, then imo that's it. Not a more generic "the first display is
> the preferred one" because frankly we don't know that - or how do you
> guess that I want to use my laptop just as a work-station, and never use
> the integrated panel when the hdmi thing is connected? You need
> configurability in userspace and fbdev for that.

I can't guess, which is why we added this parameter. I agree that 
(ignoring fbdev for now) the userspace should handle this. But as 
described in drm_helper_move_panel_connectors_to_head(), this isn't the 
case at the moment.

> And yes, for fbdev some fbdev option would probably be best. We already
> have options/parsing to disable/force certain connectors, we could also
> have another flag to designate it the preferred primary.

It's true that the only important thing here is the "primary", i.e. we 
don't care how the second or third displays are ordered.

We wanted to use the connector names here in the parameter, but 
connector names are not available before the connectors are created, so 
we ended up with the list of numbers...

> Also, the only thing where primary/secondary matters for fbdev emulation
> is for the vblank handling. Afaiui that was added for the gpu blob drivers
> being stupid and refusing to use kms. Definitely don't want to add huge
> driver-specific hacks for that :-)

For us it was about the fbdev size, which was setup at probe time to the 
size of the first display (Or smallest of the connected ones? I can't 
remember). We wanted the fbdev size to be the size of the "primary" display.

> Imo the fbdev one makes some sense, but if the only reason for it is the
> userspace gpu blob maybe not so much. For everything else, you need some
> form of configuration in userspace anyway. KMS doesn't have a concept of
> "primary" display, and I have no idea how we'd even make that happen
> everywhere.

We were not aiming at a "primary" display in the sense that it'd be 
something that the userspace should care about. More like a 
fallback-primary-display, in case the userspace only uses the first 
connector.

But I do agree that this feels hacky. So we can carry this in the TI 
kernel for now as a temporary measure.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki