[Freedreno] [RFC] Expanding drm_mode_modeinfo flags
Jeykumar Sankaran
jsanka at codeaurora.org
Thu Jul 18 18:18:42 UTC 2019
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
More information about the Freedreno
mailing list