Hi On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > Those are all just reasons for atomic modeset and maybe an atomic modeget > ioctl which transfers the entire blob of things. Maybe we should start > with the atomic modeget to get things rolling. Otoh you can always do that > in userspace since we assume there's only one display manager. DRM_MODE_OBJ_GET_PROPERTIES is already available and allows atomic retrieval of 'n' properties (as it calls drm_modeset_lock_all()). I guess that qualifies as what you describe with "atomic modeget"? > And for modeset we can throw efficiency of the marshalling/de-marshalling > over board (within some limits of course) since we do about 60*num_pipes > modeset/pageflip calls per second at most. And the overhead of the > encoding/decoding of the properties will be completely washed out by all > the register i/o we need to do to UC pci bars. Yepp, I fully agree. And if properties turn out to become a bottleneck, we should optimize them. Thanks David _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx