EFL/Wayland and xdg-shell

[Bryce Harrington]

A couple weeks ago I gave a talk on Wayland to the EFL folks at the
Enlightenment Developer Day in San Jose.  They've already implemented a
Wayland compositor backend, so my talk mainly speculated on Wayland's
future and on collecting feature requests and feedback from the EFL
developers.  Below is my summary of some of this feedback; hopefully if
I've mischaracterized anything they can jump in and correct me.


For the presentation, I identified Wayland-bound bits currently
gestating in Weston, listed features currently under review in
patchwork, itemized feature requests in our bug tracker, and summarized
wishlists from other desktop environments.  Emphasis was given to
xdg-shell and the need for EFL's feedback and input to help ensure
Wayland's first revision of it truly is agreed-on cross-desktop.


Considering KDE's feedback, a common theme was that xdg-shell should not
get in the way of allowing for advanced configuration, since
configurability is one of that D-E's key attributes.  The theme I picked
up talking with EFL emphasized being able to provide extreme UI
features.  For them, the important thing was that the protocol should
not impose constraints or assumptions that would limit this.

For purposes of discussion, an example might be rotated windows.  The
set geometry api takes x, y, height, and width.  How would you specify
rotation angle?

While window rotation was used more as an example of how built-in
assumptions in the API could unintentionally constrain D-E's, than as a
seriously needed feature, they did describe a number of ideas for rather
elaborate window behaviors:

  * Rotation animations with frame updates to allow widget re-layouts
    while the window is rotating.
  * Arbitrary shaped (non-rectangular) windows.  Dynamically shaped
    windows.
  * Non-linear surface movement/resizing animations and transition
    effects.

There was lots of interest in hearing more about Wayland's plans for
text-cursor-position and input-method, which are necessary for Asian
languages.  A particular question was how clients could coordinate with
the virtual keyboard input window so that it doesn't overlay where text
is being inserted.  Security is also a top concern here, to ensure
unauthorized clients can't steal keyboard input if (when) the virtual
keyboard client crashes.

Regarding splitting out libweston, they suggested looking if a
finer-grained split could be done.  For example, they would be
interested in utilizing a common monitor configuration codebase rather
than maintaining their own.  OTOH, I suspect we can do a better
(simpler) API than RANDR, that doesn't expose quite so many moving parts
to the D-E's, which may better address the crux of the problem here...

One area we could improve on X for output configuration is in how
displays are selected for a given application's surface.  A suggestion
was type descriptors for outputs, such as "laptop display",
"television", "projector", etc. so that surfaces could express an output
type affinity.  Then a movie application could request its full screen
playback surface be preferentially placed on a TV-type output, while
configuration tools would request being shown on a laptop-screen-type
output.

For screensaver inhibition, it was suggested that this be tracked 
per-surface, so that when the surface terminates the inhibition is
removed (this is essentially what xdg-screensaver tries to do, although
is specific to the client process rather than window iirc).  They also
suggested per-output blanking support so e.g. laptop lvds could be
blanked but the projector be inhibited, or when watching a movie on
dual-head, hyst the non-movie head powersaves off.  They also suggested
having a 'dim' functionality which would put the display to maximum
dimness rather than blanking it completely; I'm not sure on the use case
here or how easy it'd be to implement.

I had hoped to discuss collaboration on testing, but without specifics
there didn't seem to be strong interest.  One question was about
collecting protocol dumps for doing stability testing or performance
comparison/optimization with; while we're not doing that currently, that
sounded straightforward and like it could be useful to investigate more.


There was some confusion over what the purpose of xdg-shell really is;
it was looked at as a reference implementation rather than as a
lowest-common denominator that should be built *onto*.  So it seems that
Wayland have some messaging to do to ensure xdg-shell really is
'cross-desktop'.

Bryce