[RFC] Expanding drm_mode_modeinfo flags

[Jeykumar Sankaran]

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