2014-02-03 Peter Hutterer <peter.hutte...@who-t.net>:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface
to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not
device
specific, so it is independent of a classification or capabilities of
a
device. To the user it doesn't matter if we classify something as
touchpad
or as mouse, if middle mouse button emulation works that's the only
thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads
on
them.
Aside from setting an item, there should be calls to get the current
value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a
device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, &value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into "disable while linked device is in
use"
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the
monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to
match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping
configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle
button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to
adjust for
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part
of it is
a set of buttons for the trackstick. There's nothing to be configured
about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement
in the
softbutton area should move the pointer (I suggested that it shouldn't,
you
suggested that it should, and both of us had valid arguments, so it
needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
if a hardware button reports that it is clicked, but there is no finger
in any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
be my preference), treat this as left click (current situation with the
synaptics driver, and I guess some people would prefer this).
tbh, I'm not planning to support every potential option under the sun.
There's a fine and rather blurry line between what is a preference and
what
is merely configuration because we can't commit to a single default. I'd
rather have less configuration options and support those well and do the
synaptics approach of supporting everything but being quite bad at how
the
various options interact.
To extend this thought, even the list above is probably too detailed.
IMO tapping should just be a left, right, middle configuration for 1, 2,
3
fingers. Enabling/disabling tapping is a valid configuration but custom
button mapping is excessive (clickfinger is the same).
Likewise, there should be only one scroll method at a time, and one
option
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
As for the softbuttons config items, I'm somewhat leaning towards finger
movement in the button areas, but no clicks outside the button area. And
to
actually trigger a button, you need to start inside the button area -
which
becomes easier when you have proper finger tracking (synaptics currently
doesn't). I found that a very decent way to use the trackpad.
I have just called Sony support and they told me that on newer models
of their laptops (unlike older models like my Z23A4R) there is indeed
no visual distinction between areas for cursor movement and for
clicking, and the Windows driver is configured to accept cursor
movement even near the bottom edge (again, unlike Z23A4R). So your
model is indeed more appropriate for these new laptops (and in fact
the only one that makes sense for Sony Vaio Duo 13, because the height
of the touchpad is insufficient to accommodate both softbutton and
cursor-movement areas).
Just in case, here are the images of the touchpads.
Sony Vaio Z23A4R (2011 model) touchpad:
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
Sony Vaio Pro 13 touchpad:
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Also I don't see how the suggested interface covers the ChromeBook-style
clickpad configuration where there should be no softbuttons and the
only way to
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
hide away. we already do something similar in the synaptics driver where
we
don't initialize software buttons for macbooks because they're not
designed
for that approach. if the chromebooks are similar, restricting it to
tapping
only seems like a sensible approach.
Yes, chromebooks are similar to macbooks in this aspect. So what you
say makes sense.
--
Alexander E. Patrakov
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
