On Tue, 1 Jul 2014 10:47:19 -0700 Ping Cheng <[email protected]> wrote:
> On Mon, Jun 30, 2014 at 1:03 AM, Dmitry Kazakov <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
