On Thu, Jan 22, 2015 at 5:42 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: >> Which is pretty much what I do - you can only access the per-crtc ACTIVE >> property from the atomic ioctl, the per-connector dpms property is _not_ >> exposed through atomic. Vice-versa legacy clients wont see atomic >> properties (and hence this new one) either. > > Oh, OK. I didn't see anything obvious that would filter out the dpms > prop for non-atomic, nor do I see code to reject stuff in setprop/getprop > ioctls etc. But I suppose such stuff may be in flight and I've just not > paid attention. On the atomic side the dpms prop is simple not decoded. The driver /could/ do that itself, but that would be really pointless. In getprops atomic ioctls are filtered out for non-atomic clients. Which means that an atomic client could do a dpms on the connector through the legacy setprop ioctl, but that would be rather stupid. >> Is that good enough? > > I suppose. > > Another thing that came to mind wrt. the 'this can't fail rule' was > fb pinning. So is the rule now going to be that we need to pin even > when ACTIVE==false, or otherwise make sure all the FBs can be pinned > simultaneosly? If we don't want to everything pinned all the time when > ACTIVE==false, then we would need to prevent pinning of anything else > in the meantime to make sure we don't run out of address space. fb pinning is done irrespective of the state of active. So if you update the fb while the display pipe is off the helpers will upin/pin correctly. Imo that's totally fine, since failing to pin when setting the display back to active really isn't a great thing. And we need to be able to tell userspace when something has gone wrong with the pinning (e.g. due to giant framebuffer or something). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
