[PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

Simon Ser contact at emersion.fr
Fri Jun 22 16:36:16 UTC 2018


On June 22, 2018 4:20 PM, Dorota Czaplejewicz <dorota.czaplejewicz at puri.sm> wrote:
> Provides the ability to emulate keyboards by applications. Complementary to input-method protocol.
>
> The interface is a mirror copy of wl_keyboard, with removed serials, and added seat binding.
> ---
> Hi,
>
> this patch is another improvement to the previously sent virtual keyboard protocol. Changes compared to v2:
>
> - readded enum names
> - removed suggestion to listen to modifiers
> - clarified untrusted client behaviour
> - added destructor on virtual_keyboard_manager
> - fixed text wrapping
>
> First off, the new version of wayland-scanner looks up enums found in other xml files, so the textual reference are gone and actual enum values are used.
>
> Secondly, there was a suggestion that if the client wants to know global modifiers, it should listen to wl_keyboard.modifiers. In reality, this can only be done when the client has keyboard focus. I decided to remove this suggestion.
>
> Clarified that create_virtual_keyboard must error out with unauthorized when an untrusted client connects. That doesn't preclude making the whole virtual_keyboard_manager interface unavailable when the client is determined as untrusted ahead of time.
>
> Lastly, added a missing destructor as per Simon Ser's suggestion.
>
> I hope that we're getting closer to perfect with this revision! As usual, feedback is welcome.
>
> Cheers,
> Dorota Czaplejewicz

Hi,

Thanks for this updated version. A few comments below.

>  Makefile.am                                        |   1 +
>  unstable/virtual-keyboard/README                   |   2 +
>  .../virtual-keyboard-unstable-v1.xml               | 116 +++++++++++++++++++++
>  3 files changed, 119 insertions(+)
>  create mode 100644 unstable/virtual-keyboard/README
>  create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 1aa13cf..17cedc1 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -19,6 +19,7 @@ unstable_protocols =								\
>  	unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
>  	unstable/xdg-output/xdg-output-unstable-v1.xml				\
>  	unstable/input-timestamps/input-timestamps-unstable-v1.xml	\
> +	unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml	\
>  	$(NULL)
>
>  stable_protocols =								\
> diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
> new file mode 100644
> index 0000000..a2c646d
> --- /dev/null
> +++ b/unstable/virtual-keyboard/README
> @@ -0,0 +1,2 @@
> +Virtual keyboard protocol
> +
> diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> new file mode 100644
> index 0000000..bde55e8
> --- /dev/null
> +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> @@ -0,0 +1,116 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="virtual_keyboard_unstable_v1">
> +  <copyright>
> +    Copyright © 2008-2011  Kristian Høgsberg
> +    Copyright © 2010-2013  Intel Corporation
> +    Copyright © 2012-2013  Collabora, Ltd.
> +    Copyright © 2018       Purism SPC
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <interface name="zwp_virtual_keyboard_v1" version="1">
> +    <description summary="virtual keyboard">
> +      The virtual keyboard provides an application with requests which emulate
> +      the behaviour of a physical keyboard.
> +
> +      This interface can be used by clients on its own to provide raw input
> +      events, or it can accompany the input method protocol.
> +    </description>
> +
> +    <request name="keymap">
> +      <description summary="keyboard mapping">
> +        Provide a file descriptor to the compositor which can be memory-mapped
> +        to provide a keyboard mapping description.
> +      </description>
> +      <arg name="format" type="uint" enum="keymap_format"
> +        summary="keymap format"/>
> +      <arg name="fd" type="fd" summary="keymap file descriptor"/>
> +      <arg name="size" type="uint" summary="keymap size, in bytes"/>
> +    </request>
> +
> +    <enum name="error">
> +      <entry name="no_keymap" value="0" summary="No keymap was set"/>
> +    </enum>
> +
> +    <request name="key">
> +      <description summary="key event">
> +        A key was pressed or released.
> +        The time argument is a timestamp with millisecond granularity, with an
> +        undefined base. All requests regarding a single object must share the
> +        same clock.
> +
> +        Keymap must be set before issuing this request.
> +      </description>
> +      <arg name="time" type="uint"
> +        summary="timestamp with millisecond granularity"/>
> +      <arg name="key" type="uint" summary="key that produced the event"/>
> +      <arg name="state" type="uint" enum="key_state"
> +        summary="physical state of the key"/>
> +    </request>
> +
> +    <request name="modifiers">
> +      <description summary="modifier and group state">
> +        Notifies the compositor that the modifier and/or group state has
> +        changed, and it should update state.
> +
> +        Keymap must be set before issuing this request.
> +      </description>
> +      <arg name="mods_depressed" type="uint" summary="depressed modifiers"/>
> +      <arg name="mods_latched" type="uint" summary="latched modifiers"/>
> +      <arg name="mods_locked" type="uint" summary="locked modifiers"/>
> +      <arg name="group" type="uint" summary="keyboard layout"/>
> +    </request>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the virtual keyboard object"/>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_virtual_keyboard_manager_v1" version="1">
> +    <description summary="virtual keyboard manager">
> +      A virtual keyboard manager allows an application to provide keyboard
> +      input events as if they came from a physical keyboard.
> +
> +      If the compositor enables a keyboard to perform arbitrary actions, it
> +      should prevent untrusted clients from using this interface.
> +    </description>
> +
> +    <enum name="error">
> +      <entry name="unauthorized" value="0"
> +        summary="client not authorized to use the interface"/>
> +    </enum>

This is more of a general metaphorical question than anything else: I wonder how
we should handle unauthorized clients, and if adding an error for them is a good
idea. Generally errors are meant for protocol violations: it's clear from the
protocol spec that e.g. sending a request with a negative value will trigger a
protocol error. Also, errors are unrecoverable, they abort the whole client
(though this is being worked on).

So here we use an error, and the conditions in which the error is sent are
implementation-defined. I wonder if there's a better way to handle this
situation?

> +    <request name="create_virtual_keyboard">
> +      <description summary="Create a new virtual keyboard">
> +        Creates a new virtual keyboard associated to a seat.
> +
> +        If an untrusted client issues this request, it should receive the
> +        unauthorized error in return.
> +      </description>
> +      <arg name="seat" type="object" interface="wl_seat"/>
> +      <arg name="id" type="new_id" interface="zwp_virtual_keyboard_v1"/>
> +    </request>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the virtual keyboard manager object"/>

This description should probably specify what happens to keyboards created with
the manager when the manager is destroyed. A common practice is not to destroy
objects when the manager is destroyed, so that one can easily create the
manager, use the factory request, and immediately destroy the manager (see e.g.
wl_subcompositor).

> +    </request>
> +  </interface>
> +</protocol>
> --
> 2.14.4
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list