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
