[RFC 0/7] drm/omap: Module parameter for display order configuration

[Pekka Paalanen]

On Thu, 5 Oct 2017 13:01:50 +0300
Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> Hi,
> 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 05/10/17 12:56, Pekka Paalanen wrote:
> 
> > that's because Weston does not have a concept of main or preferred
> > display to begin with.
> > 
> > If what you refer to involves running Weston with the fbdev-backend,
> > then Weston has nothing to do with the issue. Weston only
> > uses /dev/fb0, whatever that might be and however that might work, as
> > set up by the kernel.  
> 
> No, it's with DRM backend.
> 
> If I recall right, the problem is that when you open a window, it opens
> on the first display (first DRM connector). Or (again, if I recall
> right), if the mouse pointer is on a particular display, then the window
> opens there. So no means to say "run this application and put its
> windows on the HDMI display".

Hi Tomi,

in Weston, the initial window placement is essentially random. There is
some guessing based on the current pointer location, but as there could
be several pointers, that's not reliable either. When there is no
pointer to guess from and Weston needs to pick an output, it simply
picks the first in a list. We might as well randomize it too, since all
outputs are equal in the current design. Only luck guarantees the order
in the output list.

If an application wants to show up on a specific output, there is
currently no Wayland extension that I recall to allow that, aside from
IVI-shell/LayerManager infrastructure. If you really need something on
a specific output, one way is to write a new protocol extension that
suits your use case, especially if your use case is not a normal PC
desktop.

If your use case is a normal PC desktop, then you could participate in
the xdg-shell protocol suite development to get a desktop standard for
initial window placement. That would probably be preceded by designing
a protocol extension that would let clients meaningfully choose an
initial output to begin with.

There is also the option of writing your own shell plugin to Weston, to
give you exactly the window management behaviour you want, including
the choice of the output.

The very least, there was some work towards configuring the output
layout in weston.ini that is still unfinished, which might perhaps
provide a workaround similar to changing connector ordering but with
only half the luck required. There is already a way to turn a connector
off in weston.ini, and my current work is aiming to allow
force-enabling disconnected connectors as well.

Changing connector ordering in the kernel to get Weston to do something
it has never deliberately intended in the first place is just wrong, so
please do not use Weston as a justification for this kernel module
parameter.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20171005/f6928eca/attachment.sig>