diff options
author | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2018-06-15 20:39:39 +0300 |
---|---|---|
committer | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2018-06-21 19:16:07 +0300 |
commit | 8d4f4b82155cc6774d0fd8aaafb882566f7fd5fb (patch) | |
tree | ab03c298f16f4bf3c67b755e63261fc6f0aad092 /Documentation/clearing-warn-once.txt | |
parent | c612ae0503af753c062594dcd14aecea121fa414 (diff) |
drm: Document mode_config.max_width/height as the max fb dimensions
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?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615173939.11353-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Diffstat (limited to 'Documentation/clearing-warn-once.txt')
0 files changed, 0 insertions, 0 deletions