Age | Commit message (Collapse) | Author |
|
This interface has no "enter" event. This was likely copy-pasted
from wl_pointer.set_cursor.
The event which indicates focus is proximity_in.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
The pad's interface is similar to the tool interface, a client is notified of
the pad after the tablet_added event.
The pad has three functionalities: buttons, rings and strips.
Buttons are fairly straightforward, rings and strips are separate interfaces
with pointer-axis-like source/value/frame events.
The two interfaces are effectively identical but for the actual value they
send (degrees vs normalized position).
Buttons are sequentially indexed starting with zero, unlike other protocols
where a linux/input.h-style semantic event code is used. Since we expect all
buttons to have client-specific functionality, an additional event tells the
client when a given button index is not available, usually because the
compositor assignes some function to it (e.g. mode switching, see below).
Specific to the pad device is the set_feedback request which enables a client
to set a user-defined string to display for an OSD on the current mappings.
This request is available for buttons, rings and strips.
Finally, the pad supports groups, effectively sets of button/ring/strip
configurations. Those groups may have multiple modes each, so that
users/clients may map several actions to a single element.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
The initial approach was to allow one surface to be re-used between tools,
seats and even used together as wl_pointer cursor surface. This has a few
drawbacks, most of which are related to managing the surface correctly in the
compositor. For example, the same cursor surface could have two different
hotspots. Animated cursors should animate independently rather than update at
the same time.
Furthermore: a client cannot know when a surface will cease being used as a
cursor surface. The basic assumption of "after focus out" is an implementation
detail in the compositor and unless the client unsets the cursor it is not
guaranteed that the surface is released. This again makes sharing a surface
less obvious - you cannot know if the wl_pointer surface is still in use when
you set it for a new wp_tablet_tool.
Avoid these headaches (and push some of them to the client) by simply
restricting a wl_surface to be assigned to a single tool. For the 99% use case
where we have one tablet with two tools (pen + eraser) this means we merely
get two extra surfaces, and the two don't usually share the same cursor shape
anyway. If sharing is absolutely necessary, a client may still opt to share
the underlying wl_buffer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
This is a straightforward copy/paste with a _v1 -> _v2 rename. No functional
changes otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|