From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration Date: Mon, 28 May 2018 13:55:36 +0300 Message-ID: <20180528135536.58d5d297@eldfell> References: <20180321100831.12716-1-peter.ujfalusi@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1924472565==" Return-path: Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 929CA6E2C8 for ; Mon, 28 May 2018 10:55:41 +0000 (UTC) Received: by mail-wr0-x242.google.com with SMTP id v13-v6so7880258wrp.13 for ; Mon, 28 May 2018 03:55:41 -0700 (PDT) In-Reply-To: <20180321100831.12716-1-peter.ujfalusi@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Peter Ujfalusi Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com, jsarha@ti.com List-Id: dri-devel@lists.freedesktop.org --===============1924472565== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rTZMX1DXz.hY_ukK7.LAxOR"; protocol="application/pgp-signature" --Sig_/rTZMX1DXz.hY_ukK7.LAxOR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 21 Mar 2018 12:08:25 +0200 Peter Ujfalusi wrote: > Hi, >=20 > Changes since v1: > - rebased it on drm-next > - Dropped the devm_kzalloc conversion patch >=20 > Changes since RFC: > - Comments from Laurent have been addressed: > - Get alias ID once and store it for later use in sorting > - Commit message updated for 'drm/omap: Manage the usable omap_dss_devic= e list > within omap_drm_private' patch > - I have kept the first patch to convert to use devm_kzalloc for the priv= ate > struct as I still think it is as correct as the way Laurent is proposin= g. >=20 > The series adds support for changing the order of the displays defined by= DT > display aliases. >=20 > 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 a driver-specific option instead of a generic DRM fb emulation configuration option? > There are many custom applications using DRM directly and they assume tha= t 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. > Afaik weston provides no means either to change the 'main/preferred' disp= lay. 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'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? > We have boards with LCD panel and HDMI for example and in DT the LCD is s= et as > display0, but in certain useage scenarios it is desired to have the HDMI = as the > 'main' display instead of the LCD. >=20 > With the kernel cmd line parameter it is possible to change the pre defin= ed > order without recompiling the kernel/DT. >=20 > If the board have two active displays: > 0 - LCD > 1 - HDMI > then: > omapdrm.displays=3D0,1 - represents the original order (LCD, HDMI) > omapdrm.displays=3D1,0 - represents reverse order (HDMI, LCD) > omapdrm.displays=3D0 - only the LCD is enabled > omapdrm.displays=3D1 - only the HDMI is enabled > omapdrm.displays=3D-1 - disable all displays >=20 > The first 6 patch of the series is doing some generic clean up and prepar= es the > code so the display ordering is going to be easy to add. Libweston has just received a bunch of patches rewriting the whole output configuration API. Now it allows force-enabling outputs and programming shared-CRTC clone mode. A next logical step would be to bring output layout configuration out of libweston and into weston, so that the layout could actually be configured at all. One could introduce the concept of a "primary" output at the same time and fix the window manager to do something useful with it. Thanks, pq >=20 > Regards, > Peter > --- > Peter Ujfalusi (6): > drm/omap: Allocate drm_device earlier and unref it as last step > drm/omap: Manage the usable omap_dss_device list within > omap_drm_private > drm/omap: Separate the dssdevs array setup from the connect function > drm/omap: Do dss_device (display) ordering in omap_drv.c > drm/omap: dss: Remove display ordering from dss/display.c > drm/omap: Add kernel parameter to specify the desired display order >=20 > drivers/gpu/drm/omapdrm/dss/display.c | 15 +-- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 225 +++++++++++++++++++++++++---= ------ > drivers/gpu/drm/omapdrm/omap_drv.h | 3 + > 4 files changed, 176 insertions(+), 70 deletions(-) >=20 --Sig_/rTZMX1DXz.hY_ukK7.LAxOR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlsL4CgACgkQI1/ltBGq qqeyTQ//ZjZCw/pVtmJvvjHSvCtR4Wl4lSfvIuSz/t7ISnaVEAT5Mq8FrHrA5+ye NUvHUCCMcRD6Caumz2/rQU3OAIgVc4/8pHrpzZFRN6cWjfTql4H/wJl8qQRXESmr +B2oopXtTWfUKJNwsqsWsSDbVmbumlpbWoCbBrH43JyWV4sceUfwDKz7ulXuN2tx 04zPH452J/3QBRbH8s71pZScKkqdVuBVcrRq7XMHiouHFvqMWyrWiuHrYx3Q1fpw QccnklbIa3O+yaNfCYGROvl6+PdCiUjzm/6r7UlxUJCOFn2qHrM+b5m2fC4sMtCJ ps2q8ZH2l/z5YgvzKty8znxVizplY0qwdeNJkLarfyf0VfnAhb52ZJ/0VTtn59fo aUxn9eDaG2rF8N7gNwvf/hrxKlS3BgHS2qZAlvQdppnKbb2HQuNQr2YDnjtZkySs SgFkjbnN/ovr8cV5b5hvdbDl+FBnIw/jNJUjQ08qlMSsWHLk0efjcdw0IqvqYa5D RkEW6Cm1nqyXwL07WhK6AlUVNWreWF2Elw9E07iY8vx5dbeXJLPXHcfjric3Si1D xcRtm/xZiXQG2j4sEA/eRoQkETeMm5xaG6G0KS05R+jxVgHeZu4w7O9l5dhdwEKZ rCiShVzL01LyNG7p1Fm+ol+l6vfp+VKN+N+I+Xumy9fO914m+8M= =0JQe -----END PGP SIGNATURE----- --Sig_/rTZMX1DXz.hY_ukK7.LAxOR-- --===============1924472565== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1924472565==--