[PATCH] drm: Document mode_config.max_width/height as the max fb dimensions

Daniel Vetter daniel at ffwll.ch
Mon Jun 18 09:06:55 UTC 2018


On Fri, Jun 15, 2018 at 08:39:39PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> The meaning of the mode_config max_width/height fields has not been
> entirely clear. They are used both as the max framebuffer dimensions,
> and they are also used by drm_mode_getconnector() to filter out
> any mode whose hdisplay/vdisplay exceed those limits.
> 
> Let's put it in writing that max_width/height only refrer to the max
> framebuffer dimensions, and should those be higher than the hardware
> limits for display timings the driver must validate the latter using
> some other means.
> 
> We'll keep the max_width/height usage in drm_mode_getconnector()
> because setcrtc treats hdisplay/vdisplay also as the primary plane
> width, and having a plane bigger than the max fb size doesn't make
> much sense (if we ignore scaling that is). It all works out fine
> as long as the max fb dimensions are at least equal to the max
> timing limits. If the opposite were true we may want to rethink
> what drm_mode_getconnector() does. Maybe do the mode filtering
> only for non-atomic userspace?

Defacto uapi is that if you do a modeset using the primary plane at full
res using a XRGB8888 format, it Will Work (tm). There's way too much
userspace out there that just blindly assumes that, and I think drivers
need to cope with that expectation.

That's why we have format conversion code in tinydrm, and that's why we
have fancy code in msm to use multiple hw planes if the framebuffer is
over the limit. So yeah, I think documentating the expectation that fb
limits >= scanout limits as a hard requirement for reasonable drivers
(i.e. stuff you expect a normal linux distro to boot on) seems reasonable.

Just as an aside, if you want to clarify this furhter. Ack on the patch
itself.

Cheers, Daniel
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
>  include/drm/drm_mode_config.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index fb45839179dd..f796691b2d09 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -329,10 +329,10 @@ struct drm_mode_config_funcs {
>  
>  /**
>   * struct drm_mode_config - Mode configuration control structure
> - * @min_width: minimum pixel width on this device
> - * @min_height: minimum pixel height on this device
> - * @max_width: maximum pixel width on this device
> - * @max_height: maximum pixel height on this device
> + * @min_width: minimum fb pixel width on this device
> + * @min_height: minimum fb pixel height on this device
> + * @max_width: maximum fb pixel width on this device
> + * @max_height: maximum fb pixel height on this device
>   * @funcs: core driver provided mode setting functions
>   * @fb_base: base address of the framebuffer
>   * @poll_enabled: track polling support for this device
> -- 
> 2.16.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list