[PATCH 3/3] compositor-drm: add sprite support v5
Juan Zhao
juan.j.zhao at linux.intel.com
Tue Jan 31 16:45:54 PST 2012
(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?
Thanks,
Juan
More information about the wayland-devel
mailing list