EFL/Wayland and xdg-shell

[Derek Foreman]

On 14/04/15 01:38 AM, Giulio Camuffo wrote:
> 2015-04-14 6:33 GMT+03:00 Derek Foreman <derekf at osg.samsung.com>:
>> 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.
> 
> When the output is rotated you get a geometry event with the transform
> so you can animate all you want, so that use case is already covered.

Eeeh, sort of.  That's kind of an after the fact signal.

As an example I suspect I'm going to overuse in the coming days: If the
compositor is doing some kind of window animation the drop shadows will
all be wrong until the final frame when it sends the output update.

For a full screen application I think that event is enough though.

For a really nice example of this done right, look at an iPad's settings
application after you rotate the tablet.  Everything slides nicely into
place.  Of course, that's a full screen app...

For a screen full of app windows that want to all do that at the same
time things get complicated.  The app would have to make a big window
(axis aligned bounding box of the rotating window) and shape away parts
of it with alpha?

This is of course possible, but I think it could be "better" if the
compositor helped out a bit...  Either by informing the app of its
orientation while performing the rotation, or allowing the app to set
its window rotation so it could handle it itself.

> 
>>
>>>> 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. :)
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel