From: Pekka Paalanen <ppaalanen@gmail.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org,
tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com,
jsarha@ti.com
Subject: Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration
Date: Mon, 28 May 2018 13:55:36 +0300 [thread overview]
Message-ID: <20180528135536.58d5d297@eldfell> (raw)
In-Reply-To: <20180321100831.12716-1-peter.ujfalusi@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 4442 bytes --]
On Wed, 21 Mar 2018 12:08:25 +0200
Peter Ujfalusi <peter.ujfalusi@ti.com> 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.
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 that 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' display.
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 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.
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
>
> 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(-)
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
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-28 10:55 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 ` [PATCH v2 0/6] drm/omap: Module parameter for display order configuration Laurent Pinchart
2018-05-28 10:55 ` Pekka Paalanen [this message]
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=20180528135536.58d5d297@eldfell \
--to=ppaalanen@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.