[PATCH weston 06/17] xdg-shell: Require a buffer and a wl_surface.commit for mapping a window
Jonas Ådahl
jadahl at gmail.com
Tue Apr 7 20:32:20 PDT 2015
On Tue, Apr 07, 2015 at 06:36:56PM -0700, Jasper St. Pierre wrote:
> On Tue, Apr 7, 2015 at 6:03 PM, Bryce Harrington <bryce at osg.samsung.com> wrote:
> > On Tue, Apr 07, 2015 at 05:01:21PM +0800, Jonas Ådahl wrote:
> >> Require the client to have attached (either previously committed, or
> >> newly) a buffer to the corresponding wl_surface, and that the window
> >> will not be potentially mapped until calling wl_surface.commit after
> >> having created the window. This is required to make valid double
> >> buffered xdg_surface state possible when creating a window.
> >>
> >> Currently there is no double buffered state in xdg_popup, but it should
> >> behave the same as xdg_surface, and for making it future proof in case
> >> we want to add double buffered state to xdg_popup.
> >>
> >> Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> >> ---
> >> protocol/xdg-shell.xml | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> >> index 0b6c999..d316e06 100644
> >> --- a/protocol/xdg-shell.xml
> >> +++ b/protocol/xdg-shell.xml
> >> @@ -149,6 +149,10 @@
> >> It provides requests to treat surfaces like windows, allowing to set
> >> properties like maximized, fullscreen, minimized, and to move and resize
> >> them, and associate metadata like title and app id.
> >> +
> >> + For a xdg_surface to be mapped by the compositor, the wl_surface must
> >> + have a buffer attached to it, and wl_surface.commit must have been called
> >> + after having created the xdg_surface object.
> >
> > That reads a bit awkward to me; could it be improved with the following?
> >
> > In order for the compositor to map a created xdg_surface object, a
> > buffer must first be attached to the wl_surface and
> > wl_surface.commit called.
>
> It doesn't describe the full story. wl_surface.commit needs to be
> called *after* the xdg_surface is created.
>
> I believe the wl_surface.attach and get_xdg_surface can happen in
> either order, though it might be nice to establish some form of
> standard order for that.
Not sure that is a good idea. It'd mean we have to disallow otherwise
valid non-role-assigned surfaces which seems a bit odd. We also need to
allow committing the surface without attaching a buffer so that the
compositor can configure the xdg_surface before mapping it (e.g. when
starting as maximized).
Anyway, how about:
"The client must call wl_surface.commit on the corresponding wl_surface
for the xdg_surface state to take effect. Prior to committing the new
state, it can set up initial configuration, such as maximizing or setting
a window geometry.
Even without attaching a buffer the compositor must respond to initial
committed configuration, for instance sending a configure event with
expected window geometry if the client maximized its surface during
initialization.
For a surface to be mapped by the compositor the client must have
committed both an xdg_surface state and a buffer."
?
Jonas
>
> >> </description>
> >>
> >> <request name="destroy" type="destructor">
> >> @@ -473,6 +477,10 @@
> >> The x and y arguments specify where the top left of the popup
> >> should be placed, relative to the local surface coordinates of the
> >> parent surface.
> >> +
> >> + For a xdg_popup to be mapped by the compositor, the wl_surface must
> >> + have a buffer attached to it, and wl_surface.commit must have been
> >> + called after having created the xdg_popup object.
> > As above
> >
> >> </description>
> >>
> >> <request name="destroy" type="destructor">
> >> --
> >> 2.1.4
> >>
> >> _______________________________________________
> >> wayland-devel mailing list
> >> wayland-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> --
> Jasper
More information about the wayland-devel
mailing list