We missed destroy requests in the 1.0 protocol and since the scanner
generates local-only *_destroy requests in that case we can't add
destroy requests without breaking protocol. A client needs to verify
that the server provides a version 3 seat to use the protocol destructor
so the name needs to be something else than wl_*_destroy.
v2 (Rob Bradford): Rebased, bumped the protocol versions and added since
attributes to the requests.
This format is used to specify that the key button events received are not in
relation to any key map and that the codes should be interpreted directly.
v2: Use zero for the no keymap enum value and enhance the documentation
for the enum entry.
Modes are mainly meant to be used in coordination with fullscreen in
DRIVER mode, by e.g. games. For such games what they generally want
is to match some hardware mode and resize their window for that. We
don't really need to complicate this with the scaling. So, we
keep the resolutions in HW pixels, and drop the SCALED flag (as it
is now useless).
This lets you just create e.g an 800x600 buffer of scale 1 and
fullscreen that, ignoring the output scaling factor (although you can
of course also respect it and create a 400x300 surface at scale 2).
Conceptually the mode change is treated like a scaling which overrides
the normal output scale.
The only complexity is the FILL mode where it can happen that the user
specifies a buffer of the same size as the screen, but the output has scale
2 and the buffer scale 1. Just scanning out this buffer will work, but
effectively this is a downscaling operation, as the "real" size of the surface
in pels is twice the size of the output. We solve this by allowing FILL to
downscale (but still not upscale).
This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
event. These together lets us support automatic upscaling of "old"
clients on very high resolution monitors, while allowing "new" clients
to take advantage of this to render at the higher resolution when the
surface is displayed on the scaled output.
It is similar to set_buffer_transform in that the buffer is stored in
a transformed pixels (in this case scaled). This means that if an output
is scaled we can directly use the pre-scaled buffer with additional data,
rather than having to scale it.
Additionally this adds a "scaled" flag to the wl_output.mode flags
so that clients know which resolutions are native and which are scaled.
Also, in places where the documentation was previously not clear as to
what coordinate system was used this was fleshed out.
It also adds a scaling_factor event to wl_output that specifies the
scaling of an output.
This is meant to be used for outputs with a very high DPI to tell the
client that this particular output has subpixel precision. Coordinates
in other parts of the protocol, like input events, relative window
positioning and output positioning are still in the compositor space
rather than the scaled space. However, input has subpixel precision
so you can still get input at full resolution.
This setup means global properties like mouse acceleration/speed,
pointer size, monitor geometry, etc can be specified in a "mostly
similar" resolution even on a multimonitor setup where some monitors
are low dpi and some are e.g. retina-class outputs.
This add a wl_output.done event which is send after every group
of events caused by some property change. This allows clients to treat
changes touching multiple events in an atomic fashion.
Fix summary for wl_touch::motion, extend summary for wl_touch::down to match
up/motion a bit better.
Fix a typo in wl_touch, and claim that it's zero or more update events, not
one or more.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove "mice, for example", it's described in the wl_pointer interface in
detail. And remove space before the full stop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a few missing summaries and descriptions, spell out file
descriptor, use hyphens in drag-and-drop, don't use hyphens in
'mime type', and reword a few things.
To match the Weston commit e7144fd175d1d68b91aa0cec7ab63381b79385a9:
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Mon Mar 4 12:11:41 2013 -0500
compositor: Only send release event in response to wl_surface.attach
Remove the implicit attach semantics from wl_surface.commit and .attach.
Before, if you did this on a wl_surface: attach, commit, commit, you
would receive wl_buffer.release for both commits. After this change, you
will only receive wl_buffer.release for the first commit. To get a
second release, the same buffer must be attached again.
There is no need for the implicit attach on the second commit. If the
compositor needs the wl_buffer for repainting, it will not release it to
begin with. If the compositor does not need to keep the wl_buffer around
for repainting, it will not need it for a new commit either.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This request allows a client to render its contents according to the
output transform, enabling the compositor to use optimizations such as
overlays, hardware cursors, scan out of a client buffer for
fullscreen surface, etc, even if the output is rotated.
5909dddc78 removed protocol/Makefile.am
which meant protocol/wayland.xml no longer got included in the tarball.
Add back protocol/Makefile.am and configure.ac bits and add protocol to
subdirs in Makefile.am to fix this.
This was added previously (commit 015c42e1) when we didn't have docbook
formatted documentation. Now it became quite useless.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Fix few typos in wl_buffer description.
Mention backing storage in wl_buffer.destroy.
Try to clarify the wl_buffer.release semantics by not explaining what
*might* happen. It is important to not suggest, that if release does not
come before frame callback, it will not come before attaching a new
buffer to the surface. We want to allow the following scenario:
The compositor is able to texture from wl_buffers directly, but it also
keeps a copy of the surface contents. The copy is updated when the
compositor is idle, to avoid the performance hit on
wl_surface.attach/commit. When the copy completes some time later, the
server sends the release event. If the client has not yet allocated a
second buffer (e.g. it updates rarely), it can reuse the old buffer.
Reported-by: John Kåre Alsaker <john.kare.alsaker@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
wl_surface.commit itself does not force any repainting unless there is
damage, so change the wording to not imply repainting.
Reported-by: John Kåre Alsaker <john.kare.alsaker@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Explicitly say what happens with the wl_buffer.release event, if you
attach several wl_buffers without a commit in between.
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The previous clarification did not follow the current implementation in
Weston, where when a surface stops being a cursor or an icon, it becomes
a plain unmapped surface again.
Rewrite the related paragraphs, and fix some typos while at it.
For start drag, make it explicit of which surface argument we are
talking about.
v2:
Make the input region undefined when the use ends. Most likely no-one
will re-use these surfaces for anything else than the same use case, so
leave some slack for the implementations to avoid useless work on
resetting the regions.
Reported-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
