[PATCH v2 0/6] drm/omap: Module parameter for display order configuration
ppaalanen at gmail.com
Mon May 28 10:55:36 UTC 2018
On Wed, 21 Mar 2018 12:08:25 +0200
Peter Ujfalusi <peter.ujfalusi at ti.com> wrote:
> 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.
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
> 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
> 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.
> 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
> 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(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the dri-devel