On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote:
> 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.
Agree that an atomic flag on a commit is the way to accomplish this. It's pretty
similar to the psr transitions, where we want to reuse most of the atomic
circuitry, but in a specialized way. We'd also have to be careful to only
involve the drm objects which are seamless modeset aware (you could imagine
a bridge chain where the bridges downstream of the first bridge don't care).
>
> 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.
Connector property? Possibly a terrible idea, but I wonder if we could [re]use
the vrr properties for command mode. The docs state that the driver has the
option of putting upper and lower bounds on the refresh rate.
Sean
> -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
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
