[PATCHv2] Add surface-layers protocol

[Drew DeVault]

On 2017-01-20 , Yong Bakos wrote:
> Across the board, would be nice to have summary attributes where they
> are missing.

Will add those for the final patch. Omitted them where they seemed
superfluous.

> I just noticed that this, and the linux-dmabuf-unstable protocol have different
> copyright notices from the rest of the protocols Wayland source. Not sure if
> this matters or not.

I just copied this from another protocol, don't recall which. Could have
been an old version.

> > +      wl_surfaces. These surfaces are assigned a size by the compositor
> > +      (generally understood to be the size of the output) and are rendered with
> > +      a z-depth that corresponds to the layer they are among.
> 
> to the surface_layer type? (This last phrase is a bit cumbersome to understand.)

I should rework this anyway, this revision of the protocol doesn't have
the assumption that the size is the size of the output.

> > +        These flags are a bitfield and are used by set_interactive to specify
> > +        what sorts of input the surface should interact with.
> > +      </description>
> > +      <arg name="none" value="0x0" />
> > +      <arg name="pointer" value="0x1" />
> > +      <arg name="keyboard" value="0x2" />
> > +      <arg name="touch" value="0x4" />
> 
> Hm, what's the use case for a layer_surface to be interactive, but only via certain
> modalities and not others?

For example, a layer might provide the ability to bind gestures to
commands and only grab touch. A panel might want the pointer but not
need the keyboard - note that it would capture all keyboard input if it
asked for it.

> > +
> > +        By convention, conventional compositors will send input events to
> > +        surfaces below the shell surface layer when there are no shell surfaces
> > +        or when the surface is clicked (and thus receives focus). Above the
> > +        shell surface layer, the topmost surface receives all input of the types
> > +        it requests.
> > +      </description>
> > +      <arg name="types" type="uint" summary="mask of input devices to use"/>
> > +    </request>
> > +
> > +    <enum name="anchor">
> > +      <description summary="corners to anchor surfaces to">
> > +        Specifies the corners and edges of an output that you may anchor the
> > +        surface to.
> > +      </description>
> > +
> > +      <entry name="top_left" value="1"/>
> > +      <entry name="top" value="2"/>
> > +      <entry name="top_right" value="3"/>
> > +      <entry name="right" value="4"/>
> > +      <entry name="bottom_right" value="5"/>
> > +      <entry name="bottom" value="6"/>
> > +      <entry name="bottom_left" value="7"/>
> > +      <entry name="left" value="8"/>
> > +      <entry name="center" value="9"/>
> 
> Consider ordering these to be congruent with some similar entries in
> wayland.xml and xdg-shell-unstable. (Despite this, I'm a fan of clockwise from
> the top, too.)

I'm not sure that would be useful, though I'm not necessarily opposed.

--
Drew DeVault

-- 
Drew DeVault