On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote:
> 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;
Not even close :-)
I mean the DRM_MODE_ATOMIC_ALLOW_MODESET flag for the atomic ioctl. This
is not a property of a mode, this is a property of a _transition_ between
configurations. Some transitions can be done flicker free, others can't.
There's then still the question of how to pick video vs command mode, but
imo better to start with implementing the transition behaviour correctly
first.
-Daniel
>
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
