EFL/Wayland and xdg-shell

Tue Apr 14 18:39:03 PDT 2015

On Tue, 14 Apr 2015 01:31:56 +0100 Daniel Stone <daniel at fooishbar.org> said:

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

see my reply to jasper. imagine the app has to be aware of rotation. :)

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

not esoteric - an actual request from people making products.

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

it is.

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

actually the other way around... clients know where the vkbd region(s) are so
client can shuffle content to be visible. :)

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

agreed - exposing randr is not sane. it's an internal compositor matter at this
level of detail (if compositor chooses to have a protocol, do it al itself
internally etc. is up to it, but any tool to configure screen output at this
level would be compositor specific).

what i do think is needed is a list of screens with some kind of types attached
and rough metadata like one screen is left or right of another (so clients like
flight simulators could ask to have special surface on the left/right screens
showing views out the sides of the cockpit and middle screen is out the front).
something like:

0 desktop primary
1 desktop left_of primary
2 desktop right_of primary
3 mobile detached
4 tv above primary

(pretend a phone with 4 external monitors attached). perhaps listing
resolution, rotation and dpi as well (pick the screen with the biggest physical
size or highest dpi - adjust window contents based on screen rotation - eg so
some controls are always facing the "bottom edge" of the screen where some
button controls are - the screen shows the "legend" text).

apps should not be configuring any of this. it's read-only. surfaces should be
able to hint at usage - eg "i want to be on the biggest tv". "i want to be
wherever you have a small mobile touch screen" etc. compositor deals with
deciding where they would go based on the current state of the world
screen-wise and app hints.

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

well at least "which screen to go on" imho would be a core hint/feature for
xdg-shell. listing screens like above would be another extension.

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

indeed. which is why we like it. it makes life simple to have smart behavior
for the "desktop as a whole".

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

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com