Comments about adding tablet support to Wayland

Pekka Paalanen ppaalanen at gmail.com
Tue Jul 1 12:25:02 PDT 2014


On Tue, 1 Jul 2014 10:47:19 -0700
Ping Cheng <pinglinux at gmail.com> wrote:

> On Mon, Jun 30, 2014 at 1:03 AM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
> > Hi, all!
> >
> > I'd like to add about mapping of the tablet input.
> >
> > In XInput one can assign a matrix transfromation for each tablet device,
> > which is exactly what people need.
> 
> If we support matrix transformation in libinput/Wayland, all "tablet
> to screen" mapping requests would be met, including my mapping to
> windows.

I would like to clarify a thing that to me seems to be getting
confused here.

Wayland protocol and libinput API are two very different worlds.
You should not clump them together.

The Wayland protocol design must take into account things like how
the compositor will choose which client gets what events, and
through which protocol interfaces. Clients have no idea about any
global or even per-output coordinate systems, all they know is the
per-surface coordinate system. If you want some other coordinate
system, like something that allows the client to map the whole
tablet area to some sub-region of a surface, you have create and
define such a coordinate system in the protocol.

Say, you want to support matrix transformation. What does that
mean? Who can set the matrix? Who will be affected by the matrix?
Why would a client want to set a matrix, when it can just receive
coordinates with events and transform them itself?

We have this idea in Wayland, that clients should not to be
able to mess up other clients, or the desktop. That means that you
cannot really make a free-for-all protocol for setting an input
transformation matrix, that affects all clients or the whole
desktop. Any client would be able to set any random matrix, messing
up the whole tablet. Even if clients were not malicious
intentionally, they could end up fighting each other on setting
globally effective configurations.

An example of this idea is the (lack of) video mode changing
protocol. There is no public protocol interface for doing 'xrandr'
commands. Instead, clients can ask to be fullscreen and give a hint
on how they would like to be presented, if the image they use does
not match the screen resolution. One option there is that the
compositor may switch the video mode, when it is appropriate. As
the compositor is in charge, you can just alt+tab away from a game
and get your normal resolution back. If the game crashes, the
compositor automatically restores your normal video mode. Etc.

My point here is that we should be more explicit on whether we are
discussing the Wayland protocol *or* libinput API.

Device configuration is one thing, but it has no place in the
public Wayland protocol intended to be used by any and all
clients/applications.


Thanks,
pq


More information about the wayland-devel mailing list