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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
