linux-kernel - Re: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Nov 2023 17:24:51 +0200
From:   Pekka Paalanen <pekka.paalanen@...labora.com>
To:     Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Simon Ser <contact@...rsion.fr>,
        Sima Vetter <daniel.vetter@...ll.ch>,
        Bilal Elmoussaoui <belmouss@...hat.com>,
        Javier Martinez Canillas <javierm@...hat.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Maxime Ripard <mripard@...nel.org>,
        Erico Nunes <nunes.erico@...il.com>
Subject: Re: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc

On Thu, 16 Nov 2023 13:34:07 +0100
Thomas Zimmermann <tzimmermann@...e.de> wrote:

> Hi
> 
> Am 16.11.23 um 13:14 schrieb Simon Ser:
> > On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann <tzimmermann@...e.de> 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

Content of type "application/pgp-signature" skipped