On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: > No, not really. I was just trying to get away with pushing some > complexity (for case #1) up to userspace instead of doing it in the > kernel. To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term. Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915. -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
