On Thu, 5 Oct 2017 13:01:50 +0300 Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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
Attachment:
pgpphTcVKrQwj.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
