On Mon, Nov 08, 2021 at 10:32:04AM -0500, Kazlauskas, Nicholas wrote:
> On 2021-11-08 10:07 a.m., Daniel Vetter wrote:
> > On Fri, Nov 05, 2021 at 04:47:29PM -0400, Kazlauskas, Nicholas wrote:
> > > Hi Daniel,
> > >
> > > Just got bitten by this warning when trying to do some refactoring in
> > >
On 2021-11-08 10:07 a.m., Daniel Vetter wrote:
On Fri, Nov 05, 2021 at 04:47:29PM -0400, Kazlauskas, Nicholas wrote:
Hi Daniel,
Just got bitten by this warning when trying to do some refactoring in amdgpu
for trying to get rid of the DRM private object we use for our DC state.
From a userspac
On Fri, Nov 05, 2021 at 04:47:29PM -0400, Kazlauskas, Nicholas wrote:
> Hi Daniel,
>
> Just got bitten by this warning when trying to do some refactoring in amdgpu
> for trying to get rid of the DRM private object we use for our DC state.
>
> From a userspace perspective I understand that we want
Hi Daniel,
Just got bitten by this warning when trying to do some refactoring in
amdgpu for trying to get rid of the DRM private object we use for our DC
state.
From a userspace perspective I understand that we want to avoid judder,
-EBUSY and other issues affecting the compositor from kerne
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
