On Wed, 18 Apr 2012 17:55:15 +0200 Marcus Lorentzon <marcus.xm.lorentzon@xxxxxxxxxxxxxx> wrote: > The async vs sync makes sense as reason for splitting them. My problem > lies somewhere in between sync modeset and async flip - async > crtc/plane/fbs modeset. > In Wayland and Android HW composer I need to asynchronously flip and do > crtc/plane modeset, but no connector/crtc modeset (so it is a fast > operation). Because I don't consider enable/disable/move a plane to be a > full synchronous modeset (same mode different fbs/planes). But I still > want the same async events to tell me the new plane setup is activated > at vsync. But as you say, maybe the biggest issue here is the "big drm > lock". So maybe user space would be ok to do this crtc-modeset in sync > mode, if it doesn't block other operations on other crtcs. But I would > prefer to be able to do the crtc modeset async so I don't have to have a > thread per crtc. Or am I missing the obvious solution to this? I don't think you're missing anything here; the obvious solution is the nuclear page flip. It's what I always envisioned would be needed once we had the basic sprite support in place. Basically we need a new page flip ioctl (which is async and gives you events) but that takes multiple planes as args, along with ancillary data. Neither setcrtc nor setplane are the right place to put this. Neither take all the info we want, and historically setcrtc didn't emit an event, so I didn't add it to setplane (it would be of limited usefulness anyway since we really want to flip primary + sprite at the same time). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
