EFL/Wayland and xdg-shell

[Derek Foreman]

On 13/04/15 07:31 PM, Daniel Stone wrote:
> 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.

It's intended to allow for the usual level of EFL/Enlightenment eye candy.

I don't think having a window perpetually at a 35 degree angle is the
intended use case - having the app know that the screen has been rotated
so it can participate in a glorious animation sequence while its window
is transitioning from 0 to 90 degree rotation is.

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

Nod, that may be the way we go.  Raster's already expressed an interest
in having our own efl-shell protocol for all our needs.  Bryce and I are
trying to sift through internal requirements and figure out what, if
anything, can be shared.

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

I've been poking at it a bit lately and have a stack of bug fixes.  I
also think the compositor should be involved in the hide/show decision
instead of leaving it entirely up to the client (give the client
hide/show/auto settings...).  I've got some work done in that direction
but it's not ready for the light of day yet.

I suspect this could end up in a thread of its own though.  Assuming
text protocols are still something we want in core wayland - Jasper
seemed to indicate gnome's going its own way in this regard...

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

More than that there was talk of wanting a way for a client such as a
vkbd to get occlusion regions for the whole screen to help it lay things
out.

And for clients in general to be able to request their own occluded
regions so they could attempt to layout things around occluded areas.

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

I'm not sure this is a solved problem.  If I read the code correctly,
only one VKB can exist, and it would have to provide both overlay and
keyboard functionality.  It may be that we want different installable
keyboards and overlays that can be configured at run time.

I think the details of authenticating the correct keyboard should
probably be left out of the protocol, but limiting to a single input
provider that must do both overlay and keyboard may be worth changing at
the protocol level?

Similarly, it may be that each seat wants a different VKB provider?

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

I do like the idea of hiding the concept of outputs and connectors very
much.  :)

This still gets ugly in a hurry.  Someone's obviously going to want to
add a mode that doesn't show up in their EDID block...

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

That's much the way the internal discussion went. :)

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

Right.  And Jasper and I can continue to turn it off.  :)

I think the non-standard bit from this paragraph is wanting to have
dimability (totally a real word) and blanking be separately controlled
by a client.

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

Bryce is coming from the cairo world where cairo-trace dumps are a great
way to see where an app is sucking.  I don't know if WESGR fills (or
intends to fill) this role.

I think the important thing here is taking a full up application that's
perhaps not performing as intended and having a way to diagnose that.
Whether that's part of weston or some external protocol analyzer tool
seems fairly unimportant though...

That said, yeah... reviving FITS and or moving the better parts of it
into weston's test suite seems like a great idea to me. :)