[RFC] Expanding drm_mode_modeinfo flags

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch