On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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. right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-) BR, -R > -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
