From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
airlied@linux.ie, tomi.valkeinen@ti.com, jsarha@ti.com
Subject: Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration
Date: Fri, 25 May 2018 23:24:28 +0300 [thread overview]
Message-ID: <1738786.yYoemFU3th@avalon> (raw)
In-Reply-To: <20180321100831.12716-1-peter.ujfalusi@ti.com>
Hi Peter,
On Wednesday, 21 March 2018 12:08:25 EEST Peter Ujfalusi wrote:
> Hi,
>
> Changes since v1:
> - rebased it on drm-next
> - Dropped the devm_kzalloc conversion patch
>
> 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_device
> list within omap_drm_private' patch
> - I have kept the first patch to convert to use devm_kzalloc for the private
> struct as I still think it is as correct as the way Laurent is proposing.
>
> 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.
> There are many custom applications using DRM directly and they assume that
> the first connector is the 'main' display.
> Afaik weston provides no means either to change the 'main/preferred'
> display.
I'm still not sure that this problem should be addressed in the kernel.
However, regardless of that, I found patches 1/6, 2/6, 4/6 and 5/6 useful for
the omapdrm cleanup and rework I'm working on.
The first version can be found in the "[PATCH/RFC 00/60] omapdrm: Reverse
direction of DSS device (dis)connect operations" patch series, and I will send
a second version in the near future.
> 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.
>
> We have boards with LCD panel and HDMI for example and in DT the LCD is set
> as display0, but in certain useage scenarios it is desired to have the HDMI
> as the 'main' display instead of the LCD.
>
> With the kernel cmd line parameter it is possible to change the pre defined
> order without recompiling the kernel/DT.
>
> If the board have two active displays:
> 0 - LCD
> 1 - HDMI
> then:
> omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
> omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
> omapdrm.displays=0 - only the LCD is enabled
> omapdrm.displays=1 - only the HDMI is enabled
> omapdrm.displays=-1 - disable all displays
>
> The first 6 patch of the series is doing some generic clean up and prepares
> the code so the display ordering is going to be easy to add.
>
> 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
>
> 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(-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-05-25 20:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 10:08 [PATCH v2 0/6] drm/omap: Module parameter for display order configuration Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 1/6] drm/omap: Allocate drm_device earlier and unref it as last step Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 2/6] drm/omap: Manage the usable omap_dss_device list within omap_drm_private Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 3/6] drm/omap: Separate the dssdevs array setup from the connect function Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 4/6] drm/omap: Do dss_device (display) ordering in omap_drv.c Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 5/6] drm/omap: dss: Remove display ordering from dss/display.c Peter Ujfalusi
2018-03-21 10:08 ` [PATCH v2 6/6] drm/omap: Add kernel parameter to specify the desired display order Peter Ujfalusi
2018-05-25 20:24 ` Laurent Pinchart [this message]
2018-05-28 10:55 ` [PATCH v2 0/6] drm/omap: Module parameter for display order configuration Pekka Paalanen
2018-05-28 11:44 ` Tomi Valkeinen
2018-05-29 6:42 ` Daniel Vetter
2018-05-29 7:16 ` Tomi Valkeinen
2018-05-29 7:48 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1738786.yYoemFU3th@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).