On Thu, 16 Nov 2023 13:34:07 +0100 Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > Hi > > Am 16.11.23 um 13:14 schrieb Simon Ser: > > On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > > >>> + * Note that there are two types of damage handling: frame damage and buffer > >>> + * damage. The type of damage handling implemented depends on a driver's upload > >>> + * target. Drivers implementing a per-plane or per-CRTC upload target need to > >>> + * handle frame damage while drivers implementing a per-buffer upload target > >>> + * need to handle buffer damage. > >>> + * > >>> + * The existing damage helpers only support the frame damage type, there is no > >>> + * buffer age support or similar damage accumulation algorithm implemented yet. > >>> + * > >>> + * Only drivers handling frame damage can use the mentiored damage helpers to > > > > Typo: mentioned > > > >>> + * iterate over the damaged regions. Drivers that handle buffer damage, need to > >>> + * set &struct drm_plane_state.ignore_damage_clips as an indication to > >>> + * drm_atomic_helper_damage_iter_init() that the damage clips should be ignored. > >>> + * In that case, the returned damage rectangle is the &drm_plane_state.src since > >>> + * a full plane update should happen. > >>> + * > >>> + * For more information about the two type of damage, see: > >>> + * https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt > >>> + * https://emersion.fr/blog/2019/intro-to-damage-tracking/ > >> > >> One thought you might want to consider. > >> > >> These URLs are helpful. The only issue I have is that frame damage and > >> buffer damage are user-space concepts. The kernel bug is that damage > >> handling expects the backing storage/upload buffer not to change for a > >> given plane. If the upload buffer changes between page flips, the new > >> upload buffer has to be updated as a whole. Hence no damage handling then. > > > > Why would these concepts be specific to user-space? The kernel could > > better handle buffer damage instead of forcing full damage, by doing > > something similar to what user-space does. > > The terms 'frame damage' and 'buffer damage' do not exist in the kernel. > The problem can be better described in wording that is common within the > context of the kernel drivers. What terms does the kernel use for these two different concepts of damage? Thanks, pq
Attachment:
pgpvBzzOMpPgZ.pgp
Description: OpenPGP digital signature
