On Mon, Aug 11, 2014 at 09:32:32AM -0400, Rob Clark wrote: > On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > Personally I'd expose a bunch of planes with kms (enough so that you can > > reap the usual benefits planes bring wrt video-playback and stuff like > > that). So perhaps something in line with what current hw does in hw and > > then double it a bit or twice - 16 planes or so. Your driver would reject > > any requests that need intermediate buffers to store render results. I.e. > > everything that can't be scanned out directly in real-time at about 60fps. > > The fun with kms planes is also that right now we have 0 standards for > > z-ordering and blending. So would need to define that first. > > > > Then expose everything else with a separate api. I guess you'll just end > > up with per-compositor userspace drivers due to the lack of a widespread > > 2d api. OpenVG is kinda dead, and cairo might not fit. > > I kind of suspect someone should really just design weston2d, an api > more explicitly for compositing.. model after OpenWFC if that fits > nicely. Or not if it doesn't. Or just use the existing weston > front-end/back-end split.. > > I expect other wayland compositors would want more or less the same > thing as weston (barring pre-existing layer-cake mess.. cough, cough, > cogl/clutter/gnome-shell..) > > We could even make a gallium statetracker implementation of weston2d > to get some usage on desktop.. There's vega already in mesa .... It just looks terribly unused. -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
