mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-20 11:47:44 +07:00
8d4f4b8215
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> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| memory | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| video | ||
| xen | ||