EFL/Wayland and xdg-shell

[Daniel Stone]

Hi,

On 14 April 2015 at 01:02, Bryce Harrington <bryce at osg.samsung.com> wrote:
> 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?

The window doesn't know it's rotated. The rotation occurs as part of
the translation into global co-ordinate space (perhaps more than one,
perhaps multiple instances, etc), which the client is unaware of. If
it wasn't unaware of it, things like input would also be broken.

> 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.

So not just animating the transition, but requesting the client
animate the content as well? That's extremely esoteric, and seems like
it belongs in a separate extension - which is possible.

>   * Arbitrary shaped (non-rectangular) windows.  Dynamically shaped
>     windows.

Entirely possible: input/opaque regions can be of arbitrary shape.

>   * Non-linear surface movement/resizing animations and transition
>     effects.

This seems like a compositor thing?

> 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.

It's sadly not been unmaintained for a while.

> 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.

See the text_cursor_position protocol.

> Security is also a top concern here, to ensure
> unauthorized clients can't steal keyboard input if (when) the virtual
> keyboard client crashes.

The compositor is responsible for starting the input method client
(VKB) and directing input. Weston is already very good at isolating
these clients from the rest; any other compositor should follow
Weston's model here.

> 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...

RandR is a disaster of an API to expose to clients. I would suggest
that anything more than a list of monitors (not outputs/connectors)
with their resolutions, relative monitor positioning, and the ability
to change/disable the above, is asking for trouble.

> 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.

A neat idea, but a separate extension to be sure. Flipping things
around a bit, you might say that the application declares its type,
and the compositor applies smart placement depending on its type.

> 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).

Very much so.

> 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.

If you have a per-surface inhibition API, per-output blanking becomes
an implementation detail.

> 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.

I'd like to see FITS revived, or the better bits of it moved into
Weston's test suite. Protocol dumps aren't particularly useful as
they're very dependent on things like exact file descriptors;
replaying a protocol dump is basically exactly what a test client
does. We can measure how quickly those run.

Cheers,
Daniel