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@ffwll.ch 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