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. Assuming the driver can do that, we > > fall back to full CRTC shutdown if not. That avoids a pile of flickering > > and unecessary modesets. > > > > But yeah downside is that the crtc is active even when unloading. Note > > Not only that, but also when you stop a DRM userspace app and don't > start a new one, the crtc stays active. Maybe that's not so common > scenario, but I wouldn't be that surprised if on embedded world someone > only runs a DRM app when they're showing something, and no app in > between the runs. > > What makes the behavior a bit funny is that if I boot without fbdev > emulation, the crtcs stay off (as they should). But run a DRM app, quit > it, and the crtcs are on. Atm the recommendation is "don't do that". And keeping display state us unchanged as possible is one of the things atomic was meant for: With solid state tracking where sw state always matches hw state you can do stuff like fastboot, i.e. take over the display state from firmware. Not a common thing on embedded things, but rather important for i915. Ofc in that case you can't use the reset helper, but instead need a hw state readout logic. > 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 :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
