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

[Daniel Vetter]

On Mon, May 28, 2018 at 02:44:28PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On 28/05/18 13:55, Pekka Paalanen wrote:
> 
> >> The series adds support for changing the order of the displays defined by DT
> >> display aliases.
> >>
> >> The motivation to do such a thing is that for example the fb emulation is
> >> treating the first display/crtc as the 'main' display and will create the
> >> fb emulation based on the first display's properties.
> > 
> > Hi,
> > 
> > catering for fbdev seems strange to me. But if you do care, why is this
> 
> Strange how? Because we should get rid of it? Sure. But it's there, and
> it's being used by almost everyone, at least in the form of fb console.
> 
> > a driver-specific option instead of a generic DRM fb emulation
> > configuration option?
> 
> That'd be fine for me, but I think the actual code to do this
> "create-connectors-in-this-order" work is still driver specific. Perhaps
> we could have a simple option to just choose the "main" display for
> fbdev (without chaing the way the connectors are created), though, which
> could perhaps be common code.

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
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.

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.

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 :-)

> >> There are many custom applications using DRM directly and they assume that the
> >> first connector is the 'main' display.
> > 
> > This is very unfortunate, but I still think it would be better to fix
> > all those apps than patch kernel drivers one at a time to cater for
> > user preferences with driver-specific kernel options.
> 
> I agree, but it's still a problem because we don't have access to those
> apps. And they keep popping up when e.g. being used on a new platform
> with multiple displays.
> 
> >> Afaik weston provides no means either to change the 'main/preferred' display.
> > 
> > Please, do not use Weston as justification for this. If you have window
> > positioning problems in Weston, please come talk to us on #wayland or
> > wayland-devel@, so we can discuss what you *actually* need.
> 
> Weston is just one piece of the puzzle. If Weston was the only problem,
> then yes, we'd be working on Weston. But it's the combination of fbdev,
> custom DRM based apps and Weston.
> 
> > Weston's behaviour in this respect has not been even defined yet, which
> > makes a kernel option to work around it ever more awkward.
> > 
> > The reason why Weston lacks this kind of configurability is that no-one
> > has needed it yet, I mean, come forth with a proposal, as far as I can
> > recall. If people keep working around it elsewhere, it is unlikely Weston
> > ever gets it.
> > 
> >> It should be the work of user space application (except the fb emulation) to
> >> somehow deal with the 'main' display selection for their needs, but
> >> unfortunately they are not capable of diong so for some reason.
> > 
> > Aside from Weston, which apps are these?
> 
> Mostly custom proprietary apps. But I think also Qt's DRM backend had
> this problem, although I might remember wrong or it might have been
> improved.
> 
> Overall, I don't like these module parameters much. But they did solve
> issues our customers were having quite easily.
> 
> I am fine with dropping this from mainline, and just carrying it in the
> TI kernel until we've come up with other solutions to the problems.

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch