Re: [RFC] Expanding drm_mode_modeinfo flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-07-16 02:07, Daniel Vetter wrote:
On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote:
    Hello All,
    	drm_mode_modeinfo::flags is a 32 bit field currently used to
    describe the properties of a connector mode. I see the least order
22 bits
    are already in use. Posting this RFC to discuss on any potential
plans to
    expand the bit range support of this field for growing mode
properties and
    ways to handle one such property needed by the msm dpu driver.

    msm drivers support panels which can dynamically switch between
video(active) and command(smart) modes. Within video mode, they also
support
switching between resolutions seamlessly i.e. glitch free resolution
switch.
    But they cannot do a seamless switch from a resolutions from video
to
    command or vice versa. Clients need to be aware for these
capablities before
    they switch between the resolutions. Since these capabilities are
identified
per drm_mode, we are considering the below two approaches to handle
this
    use case.

    Option 1:
    Attached patch adds flag values to associate a drm_mode to
video/command
    mode and to indicate its capability to do a seamless switch.

    Option 2:
    drm_mode_modeinfo can expose a new "private_flags" field to handle
vendor
    specific mode flags. Besides the above mentioned use case, we are
also
    expoloring methods to handle some of our display port resolution
switch use
    cases where the DP ports can be operated in a tiled/detiled modes.
This
approach will provide a standard channel for drm driver vendors for
their
    growing need for drm_mode specific capabilities.

    Please provide your inputs on the options or any upstream friendly
    recommendation to handle such custom use cases.

    Thanks and Regards,
    Jeykumar S.

Jeykumar Sankaran (1):
  drm: add mode flags in uapi for seamless mode switch

I think the uapi is the trivial part here, the real deal is how userspace
uses this. Can you pls post the patches for your compositor?

Also note that we already allow userspace to tell the kernel whether
flickering is ok or not for a modeset. msm driver could use that to at
least tell userspace whether a modeset change is possible. So you can
already implement glitch-free modeset changes for at least video mode.
-Daniel

I believe you are referring to the below tv property of the connector.

/**
 * @tv_flicker_reduction_property: Optional TV property to control the
 * flicker reduction mode.
 */
struct drm_property *tv_flicker_reduction_property;

Sure. We can use this to indicate whether the connector representing the panel can support the dynamic glitch-free switch. But when the panel supports both video and command mode resolutions and such glitch-free switch is possible only between video mode resolutions, we need per resolution(drm_mode_modeinfo) information
to identify the resolutions enumerated for video mode.

Below is an example of the compositor utility function which can use the tv_flicker_property
and the proposed modeinfo flags to identify glitch-free switches.

bool is_seamless_switch_supported(struct drm_mode_modeinfo src_mode, struct drm_mode_modeinfo *dst_mode, bool flicker_reduction_supported)
 {
         if (!flicker_reduction_supported) {
printf("flicker reduction prop not set for the connector\n");
                 return false;
         }

         /*
* Seamless switch(if supported) is possible only between video mode
          * resolutions
          */
         if (src_mode->flags & DRM_MODE_FLAG_VIDEO_MODE &&
                         dst_mode->flags & DRM_MODE_FLAG_VIDEO_MODE)
                 return true;
         else
                 return false;

 }


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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux