From: Jeykumar Sankaran <jsanka@codeaurora.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
linux-arm-msm@vger.kernel.org, seanpaul@chromium.org,
robdclark@gmail.com, pdhaval@codeaurora.org,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [RFC] Expanding drm_mode_modeinfo flags
Date: Thu, 18 Jul 2019 11:18:42 -0700 [thread overview]
Message-ID: <16fee2b42fa03d2cf104452223dcf5af@codeaurora.org> (raw)
In-Reply-To: <20190716090712.GY15868@phenom.ffwll.local>
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
next prev parent reply other threads:[~2019-07-18 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 18:46 [RFC] Expanding drm_mode_modeinfo flags Jeykumar Sankaran
2019-07-11 18:46 ` [RFC PATCH] drm: add mode flags in uapi for seamless mode switch Jeykumar Sankaran
2019-07-16 9:07 ` [RFC] Expanding drm_mode_modeinfo flags Daniel Vetter
2019-07-18 18:18 ` Jeykumar Sankaran [this message]
2019-07-19 9:05 ` Daniel Vetter
2019-07-19 13:55 ` Sean Paul
2019-07-19 14:15 ` Ville Syrjälä
2019-07-19 14:29 ` Sean Paul
2019-07-22 23:50 ` Jeykumar Sankaran
2019-07-23 6:56 ` Daniel Vetter
2019-07-24 14:48 ` Sean Paul
2019-07-28 17:32 ` Jeykumar Sankaran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16fee2b42fa03d2cf104452223dcf5af@codeaurora.org \
--to=jsanka@codeaurora.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=pdhaval@codeaurora.org \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).