Re: [PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 a look at this whenever I
>> happen to find some time...
> 
> I have a blog post with all the ideas from last time around we've
> discussed this:
> 
> http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html
> 
> Consensus was that we'll look at this again when someone has a real use
> case that needs it. And then maybe still decide that they just need a
> system compositor :-)

Thanks for the link. I now see this is pretty messed up (but necessary)
stuff we have =).

The situation on our embedded devices is often a bit simpler: no system
compositors, one VT, (hopefully soon) no fbdev, and we have a clear
reset state.

Reading the text makes me think the state should be somehow explicitly
passed from one compositor to the other, which would keep that state
active on the kernel side, but if that's even sanely possible, I have no
idea...

I guess I'll have to deal with this in the userspace for now, and I'll
add a helper to kms++ library which will disable and reset everything it
can.

 Tomi

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux