On Fri, 22 Jun 2018 12:36:16 -0400 Simon Ser <cont...@emersion.fr> wrote:
> On June 22, 2018 4:20 PM, Dorota Czaplejewicz <dorota.czaplejew...@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. > ---- snip ---- > > + > > + <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? > Speaking from a position of someone without a lot of Wayland experience: are Wayland errors meant to be recoverable by a client? It's obvious that if an application doing its primary task and then trying to use a restricted protocol as a secondary action crashes, that's undesireable. As a more concrete example, an automation application may use e.g. DBus API to automate tasks, and display a window to control it. It may request a virtual keyboard to extend its possibilities, but it shouldn't suddenly stop working if it's refused by the compositor. That brings me to the question: should applications using restricted protocols create additional connections which may be broken and recovered from individually or should they rather use one connection? If the latter is required for some use cases, then authorization and probing/graceful rejection should be specified inside protocols. Unfortunately, I'm not sure where to look for examples. Perhaps chat applications where screen sharing may be decided ad hoc check the marks? > > + <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). This is an oversight and will be fixed. > > > + </request> > > + </interface> > > +</protocol> > > -- > > 2.14.4 > > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
pgptxS5ZV90QL.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
