I believe your remarks and questions concern crucial points,
which probably deserve some discussion and careful examination.
Please note that behind the extension of the interface that
wsmouse provides to the hardware drivers, there is an approach
that is somewhat different from, e.g., what Linux does. And no,
I don't claim that it makes sense to compare that directly,
Linux does a lot of things that we cannot do or don't want to
do, but we must have at look it when considering ways of
porting libinput.
Linux' input module also provides a variety of state-
reporting functions and "SYNC" events and functions that
"finish" frames. Most or all of the state-reporting functions
translate the input into evdev events, sometimes with trivial,
sometimes with quite complex additional processing, but it
usually ends with generating one or more of those events.
wsmouseinput plainly uses structures that are tailored to the
different types of state, and records pending changes in their
'sync' flags. No events are generated until wsmouse_input_sync()
is called. This makes it easy to apply transformations to the
state, and all of them can be part of the sync-operation (there
is the conversion of MT input from touchpads into a single-touch
representation; for touchpads in compat mode, there is a
conversion of the single-touch state(s) into a mouse-compatible
state, and the touchpad extension is, strictly speaking, just
an addition to these transformations).
evdev events have a type, you can query evdev devices for their
capabilities, for the range of values that can occur in events
of a given type, you can filter events, and presumably do a lot
of other things. And libinput seems to be deeply rooted in evdev.
I'm not sure whether it would be possible to cleanly separate
all that evdev-specific stuff in a single layer and simply use
the rest as it is, and/or to add sufficiently evdev-like features
to our device and event system. Of course maintaining an in-kernel
touchpad driver is a burden and obligation, but it could still be
easier to support a thin libinput layer with it than adapting
everything else to a "full" libinput port.
On 12/07/2015 03:47 AM, joshua stein wrote:
On Thu, 03 Dec 2015 at 00:20:15 +0100, Ulf Brosziewski wrote:
The diffs below contain a complete and extensive rewrite of the
input-processing parts of wsmouse and the interface it provides to
the hardware drivers. It prepares the support for various kinds of
multitouch input, as well as an extended support for touchpads by
wsmouse.
It's hard to comment on the diff as a whole, so I'd recommend
breaking it up into smaller pieces that can be reviewed and
committed independently of each other. Also, please provide some
explanation of each change since it's not immediately clear from
just the code diffs why you are changing certain things.
From my initial reading, it looks like you are primarily changing
wsmouse_input to a macro that now calls separate functions for
maintaining state about buttons, motion, and pointer placement. I
think that's a good change.
I don't really agree with the direction of the trackpad driver,
though. It looks that you want to move from a "dumb" kernel
interface and a "smart" xorg driver (synaptics) to a smart kernel
interface and a dumb xorg driver (ws). Aside from wsmoused being
able to use it, what is the benefit of putting all the logic in the
kernel? I've needed to tweak synclient settings on many of my
laptops like scroll speed, multi-finger clicks, palm detection,
finger widths. Will all of that still be possible with your kernel
driver?
I know people hate libinput, but I would prefer to keep the dumb
kernel interface and be able to feed slot data to libinput to let
those upper layers handle all of the fancy logic and
configurability. That way we're not having to re-invent complicated
things like accurate palm detection in the kernel, we can keep
updating libinput from an upstream (free labor), and we'll be able
to take advantage of libinput support in things like gtk+3.
