On 28/03/17 17:22, Daniel Vetter wrote:
>> This is a bit related to the other annoyance, which is that we don't
>> reset properties when a DRM app quits. I think the state of the HW
>> should be restored to exactly the same state as it was (including
>> turning off the crtcs). I'm planning to have
On Tue, Mar 28, 2017 at 03:18:36PM +0300, Tomi Valkeinen wrote:
> On 27/03/17 10:43, Daniel Vetter wrote:
>
> > With atomic we've stopped killing the entire CRTC when you the last
> > userspace reference for the framebuffer on the primary plane disappears,
> > but just shut down the primary plane.
On 27/03/17 10:43, Daniel Vetter wrote:
> With atomic we've stopped killing the entire CRTC when you the last
> userspace reference for the framebuffer on the primary plane disappears,
> but just shut down the primary plane. Assuming the driver can do that, we
> fall back to full CRTC shutdown if
On Mon, Mar 27, 2017 at 10:15:12AM +0300, Tomi Valkeinen wrote:
> On 21/03/17 18:41, Daniel Vetter wrote:
> > The trouble here is that it does multiple atomic commits under one
> > drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> > context magic that function pulls off. It's much
On 21/03/17 18:41, Daniel Vetter wrote:
> The trouble here is that it does multiple atomic commits under one
> drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> context magic that function pulls off. It's much better to have one
> overall atomic commit. That we still have multiple
The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple atomic commits
prevents us from adding some pret
Op 21-03-17 om 16:26 schreef Daniel Vetter:
> The trouble here is that it does multiple atomic commits under one
> drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> context magic that function pulls off. It's much better to have one
> overall atomic commit. That we still have multi
The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple atomic commits
prevents us from adding some pret
Den 21.03.2017 12.22, skrev Daniel Vetter:
The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple at
The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple atomic commits
prevents us from adding some pret
10 matches
Mail list logo
