| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Here's a long story. The serial is formerly described as:
When the client receives a done event with a serial different than the
number of past commit requests, it must proceed as normal, except it
should not change the current state of the zwp_text_input_v3 object.
Upon first reading it might be obvious to interpret "proceed as normal"
as "apply the changes made by the done event" and "not change the current
state" as "do not make requests on it until serial matches with
expectations again". This would turn the serial into a flow control
mechanism to avoid pushing state changes that we know might be stale.
GTK however makes another outlandish interpretation, where "proceed as
normal" means "ignore the changes made by the done event" and "not change
state of the zwp_text_input_v3 object" is "not change client state". This
makes the serial a full synchronization mechanism where IM commands that
are deemed out of sync are symply ignored.
This would seem a misinterpretation of the protocol, and I proceeded to
change the behavior in GTK. Then some deja vu feeling struck me and I found
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864, this
change was already done and discussed in the past. Not just that, it is
the right interpretation.
However, there's some notable disadvantages, there's 2 easy ways to
completely break the synchronization between compositor and client:
Having the IM push new state too often (i.e. multiple consecutive
.done events), or having the client .commit too often. If any of both
peers gets ahead of the other slightly, the end result is ignored input.
More specifically, IBus has no provision for this kind of transactional
behavior (probably other IMs too), so implementing "emit .done once after
a set of changes" is not quite possible.
Arguably, ignoring IM input is also a bad thing. IMs expect all commands
to be respected and applied in order and might even rely on that in
their own internal state. Since only state changes are flushed on .done
events, partially ignoring IM commands will end up with the client IM state
out of sync.
The usecase described at that GNOME gitlab comment (edited text changes
happening in parallel to IM interaction) trades the handling of an
inherently racy corner case with the worst kind of mishandling (ignoring
user input) if IM/client don't perfectly sync up.
On the other hand, the flow control approach is more lenient with IMs and
clients "getting a step ahead", and more importantly does not punish the
user whenever either IM/client happens to do that. Double down on this
(already intuitively correct) description, and specify further what it
implies.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
|
|
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
|
|
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
|
|
dev_t is not a struct, it's a typedef.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Now that compositors must send INVALID to advertise support for
implicit modifiers, we can make it a protocol error to add a
DMA-BUF plane with an unsupported format + modifier pair.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
On multi-GPU setups, multiple devices can be used for rendering. Clients
need feedback about the device in use by the compositor. For instance,
if they render on another GPU, then they need to make sure the memory is
accessible between devices and that their buffers are not placed in
hidden memory.
This commit introduces a new wp_linux_dmabuf_feedback object. This
object advertises a preferred main device, a set of preferred
formats/modifiers and target devices.
Each object is bound to a wl_surface and can dynamically update its
feedback parameters. This enables fine-grained per-surface
optimizations. For instance, when a surface is scanned out on a GPU the
compositor isn't compositing with, the target device can be set to this
GPU to avoid unnecessary roundtrips.
A feedback object can also be standalone for clients that don't support
per-surface feedback.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/59
|
|
Add a note about pre-multiplied alpha for all DRM formats.
Include an escape hatch in the spec to allow other protocol
extensions to override this.
Essentially the same as [1].
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/187
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Hold gestures merely denote "there are fingers on the touchpad but they are
not moving". As touchpad touches are generally fully abstracted, a client
cannot currently know when a user is interacting with the touchpad without
moving - no motion events will be sent in this case.
The two use-cases here are:
- hold-to-interact: where a hold gesture is active for some time
a menu could pop up, or some object is selected, etc.
- hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
of a hold gesture can be used to stop the scroll
Since hold gestures by definition do not have movement, there is no need for
an "update" stage in the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
The protocol states that the client must provide xdg_toplevel surfaces,
but doesn't specify protocol error values that can be sent by the
compositor.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
This is being picky, but "pinch/spread" is the physical gesture, zoom and
rotate is the effect that clients provide in response to that gesture.
Let's use pinch only here since spread is more ambiguous in english, as anyone
who's ever had butter on their bread would know.
Also, everything else is referring to it as pinch anyway, so zoom/rotate here
is the odd one out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Currently, the spec doesn't say explicitly that present requests assign
a surface role. Given that, it can be viewed as the protocol modifies
an already assigned surface role, e.g. xdg-toplevel, and present requests
only act as hints.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
|
This commit makes it clear that compositors can send valid modifiers and
DRM_FORMAT_MOD_INVALID for a given format. This means that the compositor
supports both implicit and explicit modifiers. See the warning further
down:
> Warning: It should be an error if the format/modifier pair was not
> advertised with the modifier event. This is not enforced yet because
> some implementations always accept DRM_FORMAT_MOD_INVALID. Also
> version 2 of this protocol does not have the modifier event.
Xwayland already requires compositors to send DRM_FORMAT_MOD_INVALID
for importing buffers with an implicit modifier [1].
In a future protocol version, it would be nice to make it a protocol
error (or at least a soft failure) to use any format/modifier pair that
wasn't advertised. A use-case for this is Vulkan compositors: the Vulkan
DMA-BUF extensions require an explicit modifier and cannot import
buffers which have an implicit modifier.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/blob/6c51818a0f55282cbe5a870f58ca82ca45ee472d/hw/xwayland/xwayland-glamor-gbm.c#L328
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
This was prompted by the discussion from
https://lists.freedesktop.org/archives/dri-devel/2020-May/266611.html
which is not the final wording.
When a DRM device is hot-unplugged, particularly if it is the Wayland
compositor's compositing GPU, EGL may start returning errors from trying to use
the client's dmabuf. Or, if the client is rendering on another GPU which gets
hot-unplugged, the dmabuf the compositor already has may start failing.
Hot-unplug is an abrupt global action, and there is no way a client or a
compositor could ensure they clean up before things start failing. It is not
the client's fault, so the client should not get disconnected if already
existing wl_buffer objects start failing. This patch add the wording to the
protocol to this effect.
The intention is that the compositor replaces the failed buffers with some
placeholder content. There is no way this could be glitch-free. In its own pace
the client should discover the DRM device is gone, clean up, and perhaps use
something else. How exactly that should happen depends on the rendering API the
client is using.
This is a tiny step towards making DRM device hot-unplug not crash
applications that wish to handle the unplug gracefully.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
Currently protocol does not specify what should happen if multiple
text-inputs are created by same client, which is why this is more or
less undefined behavior currently in compositor implementations.
If client has created more than one text-input objects and surface owned
by the client is focused, then compositor must send enter event to all
text-input objects, in case of enable request however only one
text-input must be enabled per client per seat.
Signed-off-by: Bhushan Shah <bshah@kde.org>
|
|
Since the abbreviation "XDG" starts with a vowel sound, the correct
article is "an."
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
|
The output description is a human-readable text describing the output. Unlike
the name which uniquely identifies the output, it's intended to be displayed to
the user.
It might be desirable for a compositor to update an output's description. For
instance, when only one output is plugged in, it's not necessary to dump make,
model, serial and connector to the description, something like "Dell U2717D" is
enough. However when two identical outputs are plugged in it's necessary to add
e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1] for
a discussion about this.
This commit bumps xdg_output's version to allow compositors to update the
property.
[1]: https://github.com/swaywm/wlroots/issues/1623
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
|
|
This allows clients to destroy a gesture object before they disconnect.
The request isn't named "destroy", as this would conflict with
wayland-scanner's auto-generated destructor (which just destroys the
client-side object without sending any request).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This commit makes it so a wl_output.done event is guaranteed to be sent with a
xdg_output.done event.
This protocol change has been discussed in a recent xorg-devel discussions [1].
First let's recap why a change is needed: Xwayland listens to both wl_output and
xdg_output changes. When an output's properties change, Xwayland expects to
receive both a wl_output.done event and an xdg_output.done event. If that's not
the case, Xwayland doesn't update its state (so old state is still exposed to
X11 clients).
Most of the time, both objects will be updated at the same time (e.g. the
current mode is changed, so both wl_output.mode and xdg_output.logical_size are
sent) so this won't be an issue. However in some situations only one of
wl_output or xdg_output changes. For instance:
- The mode is changed at the same time as the scale, resulting in the same
logical_size.
- The compositor doesn't expose the outputs' position via wl_output, so whenever
the position changes only xdg_output is updated.
Both KDE [2] and wlroots [3] have experienced this issue.
For this reason, I'd like to update the xdg-output protocol to make it mandatory
to always send a wl_output.done event after xdg_output changes. This effectively
makes wl_output.done atomically apply all output state (including the state of
add-on objects like xdg_output). This approach is pretty similar to
wl_surface.commit: this request will atomically apply surface state including
the state of e.g. the xdg_surface object tied to the wl_surface.
To update the protocol to reflect this new requirement we can either:
- **Bump xdg_output version**. The current protocol doesn't specify that
wl_output.done must be sent, adding this new requirement would be a breaking
change. We need to fix Xwayland for the current xdg_output version (maybe make
it non-atomic for the current version, atomic for the new one?). Should we
deprecate xdg_output.done in the new version?
- **Don't bump xdg_output version**. This clarifies what is expected in practice
by Xwayland, a major xdg_output consumer, and what is currently implemented by
all compositors.
There's one issue with the "don't bump" approach: indeed in practice compositors
always send wl_output.done and xdg_output.done in pairs, however the ordering
between those two events is not guaranteed. This means some compositors might
send this sequence:
wl_output.geometry(…)
wl_output.done()
xdg_output.logical_position(…)
xdg_output.done()
In this case the wl_output.done event fails to atomically apply the xdg_output
state.
For this reason, I think bumping the version is a better approach.
This commit also deprecates xdg_output.done, which doesn't have any purpose
anymore.
[1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
[2]: https://phabricator.kde.org/D19253
[3]: https://github.com/swaywm/sway/issues/4064
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.
v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
requires a version bump)
v4: no version bump, but a note for now
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
of release events
Clarify that after zwp_buffer_release_v1 events, otherwise unused
buffers can be reused without any additional implicit synchronization.
This is in contrast to wl_buffer.release, which doesn't guarantee that
implicit synchronization is not required to safely use a buffer after
the event is received.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
graphics APIs
Graphics APIs are expected to use this protocol under the hood, and
since there can only be one user of explicit synchronization per
surface, warn about using the protocol directly in such cases.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
Add opaque EGL buffers to the supported buffer types for use with the
explicit synchronization protocol. Opaque EGL buffers rely on the same
EGL implementation in both the compositor and clients, which makes it
straightforward to manage client expectations about fence support for
such buffers.
Also make it clearer that implementations are free to support other
buffer types beyond the required ones.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
This primary selection is similar in spirit to the eponimous
in X11, allowing a quick "select text + middle click" shortcut
to copying and pasting.
It's otherwise very similar to its Wayland counterpart, and
explicitly made consistent with it.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
|
|
This protocol enables explicit synchronization of asynchronous graphics
operations on buffers on a per-commit basis. Support is currently
limited to dmabuf buffers and dma_fence fence FDs.
Explicit synchronization provides a more versatile notification
mechanism for buffer readiness and availability, and can be used to
improve efficiency by integrating with related functionality in display
and graphics APIs.
This protocol is also useful in ChromeOS ARC++ (running Android apps
inside ChromeOS, using Wayland as the communication protocol), where it
can enable integration of the ChromeOS compositor with the explicit
synchronization mechanisms of the Android display subsystem.
Finally, the per-commit nature of the release events provided by this
protocol potentially offers a solution to a deficiency of the
wl_buffer.release event (see
https://gitlab.freedesktop.org/wayland/wayland/issues/46).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[Pekka: dropped Reveman from maintainers]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
Although it would probably default to the license at the root of the
repository anyway, it's best to be explicit about it, and also be
consistent with the other extensions.
The copyright holders have been assembled from git history and the
README.
Signed-off-by: Johan Klokkhammer Helsing <johan.helsing@qt.io>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
|
|
This new protocol description is an evolution of v2.
- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
Compositors are still free to handle situations where the keyboard
focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This adds a new protocol to negotiate server-side rendering of window
decorations for xdg-toplevels. This allows compositors that want to draw
decorations themselves to send their preference to clients, and clients that
prefer server-side decorations to request them.
This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Eike Hein <hein@kde.org>
Reviewed-by: Alan Griffiths <alan.griffiths@canonical.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
|
|
This adds two events to the protocol. The goal is to allow clients to
give the user the ability to select outputs with the same names the
compositor uses and to identify outputs consistently across sessions.
The output name is a short and stiff identifier with strict limits on
permitted characters, which is suitable for storing in config files,
command line arguments, etc. A warmer "description" event is also
provided to (optionally) provide a more human readable name, and has
much broader restrictions on its form.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Jonas: Fixed formatting and commit subject]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
wl_pointer, wl_keyboard and wl_touch events currently use a 32-bit
timestamp with millisecond resolution. In some cases, notably latency
measurements, this resolution is too coarse to be useful.
This protocol provides additional high-resolution timestamps events,
which are emitted before the corresponding input event. Each timestamp
event contains a high-resolution, and ideally higher-accuracy, version
of the 'time' argument of the first subsequent supported input event.
Clients that care about high-resolution timestamps just need to keep
track of the last timestamp event they receive and associate it with the
next supported input event that arrives.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
As export is a reserved keyword in C++, in order for the output
generated by wayland_scanner to compile correctly rename export to
export_toplevel and import to import_toplevel this needs a new protocol
version as is an incompatible change
[jadahl: Fix various documentation issues]
Signed-off-by: Marco Martin <notmart@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Some methods will be renamed, so we need a new, not retrocompatible
protocol.
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
|
|
This adds a new protocol to let Wayland clients specify that they want
all keyboard events to be sent to the client, regardless of the
compositor own shortcuts.
This protocol can be used for virtual machine and remote connection
viewers which require to pass all keyboard shortcuts to the hosted or
remote system instead of being caught up by the compositor locally.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This patch introduces a new protocol for grabbing the keyboard from
Xwayland.
This is needed for X11 applications that map an override redirect window
(thus not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Unfortunately this hunk fell out during a rebase. Sorry!
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
advertise the supported fourcc format modifiers along with supported
formats to the client. the 'modifier' event introduced here is
intended to replace the 'format' event from zwp_linux_dmabuf_v1
version 1.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions to 3.
v2: specify request name in event description for clarity (Yong Bakos)
v3: grammar fixup (Yong Bakos)
v4: add deprecation warning against 'format' event usage (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
provide a mechanism that allows clients to import the added dmabufs
and immediately use the newly created wl_buffers without waiting on
an event. this is useful to clients that are sure of their import
request succeeding, and wish to avoid the wl_buffer communication
roundtrip.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions.
v2: specify using incorrectly imported dmabufs as undefined behavior
instead of sending success/failure events. (pq, daniels)
v3: preserve the optional protocol error added in v2 and explicitly
state the outcome of import success or failure (pq)
v4: clarify create_immed failure cases and error codes (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
clearly state the request name in format event to avoid abmiguous
interpretation between 'zwp_linux_buffer_params_v1::create' and
'zwp_linux_dmabuf_v1::create_params' requests.
v2: grammar fixup (Yong Bakos)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Suggested-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Enum entries and message arguments are sometimes preceded by a blank line, but
often aren't.
Standardize the format of the protocol specification by removing blank lines
preceding a list of message arguments and enum entries.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Make all the descriptions consistent by starting the description with a
simple verb (set instead of sets, etc.) Add or rework a few of the
existing descriptions to fit this form.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
|
