From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: [RFC 0/7] drm/omap: Module parameter for display order configuration Date: Thu, 5 Oct 2017 13:43:20 +0300 Message-ID: <20171005134320.2c479d1f@eldfell> References: <20170829073218.11097-1-peter.ujfalusi@ti.com> <20171005125627.08fa3890@eldfell> <46493433-ee9b-7a11-1510-95ccad17bb99@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1121612207==" Return-path: Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4CD696E192 for ; Thu, 5 Oct 2017 10:43:31 +0000 (UTC) Received: by mail-lf0-x229.google.com with SMTP id c82so12634416lfc.6 for ; Thu, 05 Oct 2017 03:43:31 -0700 (PDT) In-Reply-To: <46493433-ee9b-7a11-1510-95ccad17bb99@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen Cc: Peter Ujfalusi , laurent.pinchart@ideasonboard.com, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1121612207== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/BVlreMg=6CBzqDRvqG44q9u"; protocol="application/pgp-signature" --Sig_/BVlreMg=6CBzqDRvqG44q9u Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 5 Oct 2017 13:01:50 +0300 Tomi Valkeinen wrote: > =EF=BB=BFHi, >=20 >=20 > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/= Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >=20 > On 05/10/17 12:56, Pekka Paalanen wrote: >=20 > > that's because Weston does not have a concept of main or preferred > > display to begin with. > >=20 > > 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. =20 >=20 > No, it's with DRM backend. >=20 > 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 --Sig_/BVlreMg=6CBzqDRvqG44q9u Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlnWDMgACgkQI1/ltBGq qqf9khAAoFuoPlhiYbprzVsTLhK+NWhBF5OiYgQ2qeru1djZBeGf7r94cJOvjhDg O7RWJKoE7TU0I6Ya6L20dvUmRXxk0eFbSqEdflpT9KbKU8i5FipjB/49i7zfnldk 5GxnJKRF7IkY6pHijjFLfcV5YEg4tcaDE9nJ9Us+tt0+EEr17xMmV/Zq/LYkvpxQ EZ2l2OH6vlYeqXDe1xOsGGRSmEqPSyY0EDzCwwLB7ASs/HGwk+Y8F5TDJ5A+tG2d 1gpH1fsUP3QErgAksWe2+wM1l9xAHgoCjuFSaQW7Kl5GdHnDV0ai9IJzHwvw7ScU sF8MQrzHWJmBRI7JGzSZrZiPux63ihPhvQmuMe+Zm6yPQ5bKogs3uEVaS3qTH53K McnWisrDnt6V6xVC3DyeuhRVVnEACOlC6NOJCAdjRpK978/l09FxnJLurIVQ4sa+ EuHOYMOySK+TgHsY7jHchTp2D5Fri9Evr60/tCICoiKzKQl8nGC3XlEwhVz/pRdN T7kYFV9w6p8H5xmhxi8V6SDhmNCQeHF9TGZDb6/h3bRsKCz9sc6A1u9TdU4WVdHW NSdim1wbIYOXCPMAVVO9xye6q2Ywgoi7Dt1Nxa3cWuj5pA7CGu8jYeWIpxFHJ5pg ub9a5LR45TwkrGWXBH17UQs15lg6S9B1WLJ0bjdswwQCTCzBzGI= =sqAO -----END PGP SIGNATURE----- --Sig_/BVlreMg=6CBzqDRvqG44q9u-- --===============1121612207== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1121612207==--