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: Tue, 16 Jan 2024 15:14:14 +0200
From: Pekka Paalanen <ppaalanen@...il.com>
To: André Almeida <andrealmeid@...lia.com>
Cc: dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, kernel-dev@...lia.com,
 alexander.deucher@....com, christian.koenig@....com, Simon Ser
 <contact@...rsion.fr>, daniel@...ll.ch, Daniel Stone
 <daniel@...ishbar.org>, 'Marek Olšák' <maraeo@...il.com>,
 Dave Airlie <airlied@...il.com>, ville.syrjala@...ux.intel.com, Xaver Hugl
 <xaver.hugl@...il.com>
Subject: Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane
 check for async

On Tue, 16 Jan 2024 08:50:59 -0300
André Almeida <andrealmeid@...lia.com> wrote:

> Hi Pekka,
> 
> Em 16/01/2024 06:45, Pekka Paalanen escreveu:
> > On Tue, 16 Jan 2024 01:51:57 -0300
> > André Almeida <andrealmeid@...lia.com> wrote:
> >   
> >> Hi,
> >>
> >> AMD hardware can do more on the async flip path than just the primary plane, so
> >> to lift up the current restrictions, this patchset allows drivers to write their
> >> own check for planes for async flips.  
> > 
> > Hi,
> > 
> > what's the userspace story for this, how could userspace know it could do more?
> > What kind of userspace would take advantage of this and in what situations?
> > 
> > Or is this not meant for generic userspace?  
> 
> Sorry, I forgot to document this. So the idea is that userspace will 
> query what they can do here with DRM_MODE_ATOMIC_TEST_ONLY calls, 
> instead of having capabilities for each prop.

That's the theory, but do you have a practical example?

What other planes and props would one want change in some specific use
case?

Is it just "all or nothing", or would there be room to choose and pick
which props you change and which you don't based on what the driver
supports? If the latter, then relying on TEST_ONLY might be yet another
combinatorial explosion to iterate through.


Thanks,
pq

> >> I'm not sure if adding something new to drm_plane_funcs is the right way to do,
> >> because if we want to expand the other object types (crtc, connector) we would
> >> need to add their own drm_XXX_funcs, so feedbacks are welcome!
> >>
> >> 	André
> >>
> >> André Almeida (2):
> >>    drm/atomic: Allow drivers to write their own plane check for async
> >>      flips
> >>    drm/amdgpu: Implement check_async_props for planes
> >>
> >>   .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 30 +++++++++
> >>   drivers/gpu/drm/drm_atomic_uapi.c             | 62 ++++++++++++++-----
> >>   include/drm/drm_atomic_uapi.h                 | 12 ++++
> >>   include/drm/drm_plane.h                       |  5 ++
> >>   4 files changed, 92 insertions(+), 17 deletions(-)
> >>  
> >   


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ