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
