Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Peter,

On Tuesday, 29 August 2017 10:32:11 EEST Peter Ujfalusi wrote:
> Hi
> 
> 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.
> 
> 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.

One could argue that the DT should then be updated. The device tree is a 
description of the whole system, not just the board. If a board is integrated 
in a system that makes HDMI the primary display, it would make sense for DT to 
reflect that.

> 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.

This will conflict with the work I'm doing on merging the omapdrm and omapdss 
driver, so I'm a bit reluctant to merge this first :-/ In particular, with the 
two drivers merged, couldn't we implement this module parameter without moving 
the display sorting from omapdss to omapdrm ?

> ---
> Peter Ujfalusi (7):
>   drm/omap: Use devm_kzalloc() to allocate omap_drm_private
>   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    | 244 +++++++++++++++++++++----------
>  drivers/gpu/drm/omapdrm/omap_drv.h    |   3 +
>  4 files changed, 183 insertions(+), 82 deletions(-)

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel