[PATCH 3/3] compositor-drm: add sprite support v5

[Pekka Paalanen]

On Wed, 01 Feb 2012 08:45:54 +0800
Juan Zhao <juan.j.zhao at linux.intel.com> wrote:

> (looking forward to wonderful sprite support in wayland. I have a
> question related to fullscreen support here.)
> 
> On Tue, 2012-01-31 at 09:27 -0800, Jesse Barnes wrote:
> > Thanks for checking it out...
> > 
> > On Tue, 31 Jan 2012 11:11:11 +0200
> > Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > > +static int
> > > > +surface_is_cursor(struct weston_compositor *ec, struct
> > weston_surface *es)
> > > > +{
> > > > +   if (!es->buffer)
> > > > +           return -1;
> > > > +   return 0;
> > > > +}
> > > 
> > > Recalling what krh once said to me, I think also the "normal"
> > surfaces
> > > may have no buffer, if the client destroys it. The surface may still
> > > exist and be drawn as the compositor "copied" the pixels. That was
> > when
> > > I asked about using the buffer width & height instead of duplicating
> > it
> > > in weston_surface.
> > > 
> > > But looking at the code, it seems the buffer release event is posted
> > > only after the buffer is really is not used anymore, and not
> > > immediately when the pixels have been acquired. So I'm not sure what
> > the
> > > life time should be.
> > 
> > Yeah I'm not quite sure about this one either.  This particular call
> > will be dropped once we incorporate the hw cursor code here.  In
> > testing, the only surface I found w/o a buffer was the cursor, but
> > I'll
> > admit it was pretty trivial testing.  But that's the real requirement
> > anyway; in order to put a surface on a sprite, you need a buffer you
> > can turn into a bo...
> 
> Is there any general method to check whether a surface is cursor? 
> 
> For full screen support, we need to pick out the cursor and panel
> surfaces. Adding one interface to weston_surface named type can
> differentiate the cursor, panel and general surfaces. How do you feel
> about this proposal? Any suggestions?

IMHO, that is just a sub-problem in your workaround to the real
problem of not being able to easily handle the window stack. Still, I
don't have any good suggestions.

For reference, from irc recently:

< krh> the surface stacking need a better data structure
< krh> anderco: I've been thinking that as a short term solution we can have dummy surf
aces in the list that mark the different layers
< krh> make sure they dont take input or get painted etc
< krh> and then we can insert cursor sprites under the cursor_layer surface
< krh> and surfaces under the surface_layer dummy surface etc
< krh> and a background_layer
< krh> alternatively, we could just man up and make a surface tree
< krh> but have a flattened list that we use fo the region math
< krh> and mark the list dirty when the tree changes and regenerate it when we need to
 * krh keeps talking to himself

Maybe there is a stronger opinion after FOSDEM, if you can wait.


Thanks,
pq