Comment on Wayland anti-FUD

[Peter Hutterer]

On Wed, May 16, 2012 at 10:10:37AM +0300, Pekka Paalanen wrote:
> On Wed, 16 May 2012 11:39:06 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > On Sat, May 12, 2012 at 01:16:38PM +0300, Pekka Paalanen wrote:
> > 
> > [snip]
> > 
> ...
> > > You are right about input plugins, but there are couple things
> > > that should make it not so bad:
> > > - a majority of input devices are evdev, so we mostly need only
> > > an evdev plugin
> > 
> > there are 3 X input drivers that matter to most people these days. evdev,
> > synaptics and wacom. All three are evdev drivers on Linux. the reason we
> > still have three of them is because the handling of the devices is complex -
> > what you want from a touchpad is different than what you want from a
> > keyboard.
> > 
> > you could bunch all of them up into a single driver and wayland doesn't have
> > the client legacy that X has but what you'll end up doing is moving the
> > touchpad/wacom-specific sections into the clients. and then you hope that
> > all clients have the same setup because otherwise that software-emulated
> > button on your touchpad won't work in some clients but will in others.
> > 
> > I suspect there will be a need for multiple plugins sooner or later, even if
> > all of them speak evdev.
> 
> Thanks for clarifying that!
> 
> Multiple plugins, or an input library a little like what Mesa (or
> Gallium3D) is with hw gfx drivers? In Wayland, all the ones you
> mentioned would probably need to be supported in the core input
> protocol, right? Could that serve as a model for a unified input
> library API, too?

I don't want to claim I've got the solution (I don't, still trying to find
something that makes sense) but it may be two-layered. Some library that
handles the input device semantics inside the compositor and some library
(possibly the same one) that handles them inside the client.

Likely the same though. The example here is edge scrolling in touchpads -
the compositor needs to know so it doesn't move the pointer but clients need
to know so they can scroll in the same manner as for two-finger scrolling.

> I'm not clearly seeing why you say the specifics would be moved into
> clients, unless they want to bypass the server event filtering and use
> raw Wayland input events (which we don't have yet, AFAIK).

Specific example here: software-emulated buttons on clickpads. Are you going
to send a right button event (the hw will give you a left button) to the
client? if so, it needs to be associated with the raw event so the client
knows it shouldn't interpret the raw event as left button event.

if you move the interpretation into the client completely, you miss out on
compositor/WM interactions using said buttons. Plus, then you run the risk
of having two clients interpret the same action differently, based on
whatever input interpretation lib they use.

so I think there is a need for a shared input handling module used by the
compositor and the client. don't ask me how that will look like though :)
 
Cheers,
  Peter