Discussion:
[RFC] libinput configuration interface
(too old to reply)
Peter Hutterer
2014-01-31 01:05:29 UTC
Permalink
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?

Cheers,
Peter
Alexander E. Patrakov
2014-01-31 14:26:54 UTC
Permalink
Post by Peter Hutterer
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.
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);
* {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).

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.
--
Alexander E. Patrakov
Peter Hutterer
2014-02-03 01:02:42 UTC
Permalink
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
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);
* {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.

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.
Post by Alexander E. Patrakov
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.

Cheers,
Peter
Alexander E. Patrakov
2014-02-03 05:11:51 UTC
Permalink
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
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);
* {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.
Post by Peter Hutterer
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:
Loading Image...

Sony Vaio Pro 13 touchpad:
Loading Image...
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Eugen Friedrich
2014-02-06 22:28:49 UTC
Permalink
Hi together,
i would like to put some input from the embedded/ automotive perspective.

you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.

The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.

Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.

What do you think?
Post by Peter Hutterer
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
I've been thinking about how to add a device configuration interface
to
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
specific, so it is independent of a classification or capabilities of
a
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
device. To the user it doesn't matter if we classify something as
touchpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
or as mouse, if middle mouse button emulation works that's the only
thing
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
them.
Aside from setting an item, there should be calls to get the current
value,
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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);
* {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"
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
* 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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
could be an API taking nfingers as argument as opposed to 3 different
calls.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
Likewise, they can take more than one value argument, e.g. middle
button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
a set of buttons for the trackstick. There's nothing to be configured
about
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area should move the pointer (I suggested that it shouldn't,
you
Post by Peter Hutterer
Post by Alexander E. Patrakov
suggested that it should, and both of us had valid arguments, so it
needs to
Post by Peter Hutterer
Post by Alexander E. Patrakov
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
if a hardware button reports that it is clicked, but there is no finger
in any
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
Post by Peter Hutterer
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
Post by Peter Hutterer
actually trigger a button, you need to start inside the button area -
which
Post by Peter Hutterer
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.
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
Post by Peter Hutterer
hide away. we already do something similar in the synaptics driver where
we
Post by Peter Hutterer
don't initialize software buttons for macbooks because they're not
designed
Post by Peter Hutterer
for that approach. if the chromebooks are similar, restricting it to
tapping
Post by Peter Hutterer
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140206/a1e07b8d/attachment-0001.html>
Jonas Ådahl
2014-02-07 08:52:42 UTC
Permalink
Post by Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
I'm not completely sure what you are talking about. Do you mean you want
configurable button (and scroll) areas of touch pad or tablet devices? I.e.
not a touch device that has a built in output screen. The idea, AFAIK, is
that for various touchpad devices, these kind of details should be internal
to the libinput device backend in question. That being said, this
doesn't make it impossible to introduce such configuration in the
future.
Post by Eugen Friedrich
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
This calibration, based on an udev rule, is already possible in libinput.
It is automatic when using the udev backend it is possible to manually
calibrate using libinput_device_calibrate() when using the path backend.
Post by Eugen Friedrich
What do you think?
Post by Peter Hutterer
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
I've been thinking about how to add a device configuration interface
to
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
specific, so it is independent of a classification or capabilities of
a
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
device. To the user it doesn't matter if we classify something as
touchpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
or as mouse, if middle mouse button emulation works that's the only
thing
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
them.
Aside from setting an item, there should be calls to get the current
value,
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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);
* {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"
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
* 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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
could be an API taking nfingers as argument as opposed to 3 different
calls.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
Likewise, they can take more than one value argument, e.g. middle
button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
a set of buttons for the trackstick. There's nothing to be configured
about
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area should move the pointer (I suggested that it shouldn't,
you
Post by Peter Hutterer
Post by Alexander E. Patrakov
suggested that it should, and both of us had valid arguments, so it
needs to
Post by Peter Hutterer
Post by Alexander E. Patrakov
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
if a hardware button reports that it is clicked, but there is no finger
in any
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
Post by Peter Hutterer
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
Post by Peter Hutterer
actually trigger a button, you need to start inside the button area -
which
Post by Peter Hutterer
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.
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
Post by Peter Hutterer
hide away. we already do something similar in the synaptics driver where
we
Post by Peter Hutterer
don't initialize software buttons for macbooks because they're not
designed
Post by Peter Hutterer
for that approach. if the chromebooks are similar, restricting it to
tapping
Post by Peter Hutterer
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Eugen Friedrich
2014-02-08 22:18:01 UTC
Permalink
Hallo Jonas,
Thanks for fast replay, basically we have already proprietary
implementation in place to fulfil requirements from different customers.
Now we are looking forward to find a good open source component to
contribute our knowledge, experience and maybe code.
Since we using wayland, libinput library will be a perfect candidate.

The aim of my email was to find out if our requirements/ ideas are
acceptable for the community. I notice that you start discussion about
the configuration of the libinput library and thought it a good time to
put my 2 cents. If the first ideas makes sense for community we will
come up with a concrete requirements and proposals.
Post by Jonas Ådahl
Post by Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
I'm not completely sure what you are talking about. Do you mean you want
configurable button (and scroll) areas of touch pad or tablet devices? I.e.
not a touch device that has a built in output screen. The idea, AFAIK, is
that for various touchpad devices, these kind of details should be internal
to the libinput device backend in question. That being said, this
doesn't make it impossible to introduce such configuration in the
future.
Yes, I was thinking about adding configuration for new devices with
configurable button and scroll areas.
If you have to develop a new device e.g. smartphone where the virtual
buttons are outside of the screen area. In this case the touch driver
has to take care of sending an button event when user touch the
particular area of the touch panel.
The proposed configuration will make you independent of specific driver
implementation and you can use different touch panels and putt you
buttons/scroll areas wherever you wont.
Post by Jonas Ådahl
Post by Eugen Friedrich
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
This calibration, based on an udev rule, is already possible in libinput.
It is automatic when using the udev backend it is possible to manually
calibrate using libinput_device_calibrate() when using the path backend.
Yes, thanks for the advice I saw it. The available configuration covers
already a part from our requirements.
Post by Jonas Ådahl
Post by Eugen Friedrich
What do you think?
Post by Peter Hutterer
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
I've been thinking about how to add a device configuration interface
to
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
specific, so it is independent of a classification or capabilities of
a
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
device. To the user it doesn't matter if we classify something as
touchpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
or as mouse, if middle mouse button emulation works that's the only
thing
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
them.
Aside from setting an item, there should be calls to get the current
value,
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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);
* {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"
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
* 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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
could be an API taking nfingers as argument as opposed to 3 different
calls.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
Likewise, they can take more than one value argument, e.g. middle
button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
a set of buttons for the trackstick. There's nothing to be configured
about
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area should move the pointer (I suggested that it shouldn't,
you
Post by Peter Hutterer
Post by Alexander E. Patrakov
suggested that it should, and both of us had valid arguments, so it
needs to
Post by Peter Hutterer
Post by Alexander E. Patrakov
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
if a hardware button reports that it is clicked, but there is no finger
in any
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
Post by Peter Hutterer
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
Post by Peter Hutterer
actually trigger a button, you need to start inside the button area -
which
Post by Peter Hutterer
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.
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
Post by Peter Hutterer
hide away. we already do something similar in the synaptics driver where
we
Post by Peter Hutterer
don't initialize software buttons for macbooks because they're not
designed
Post by Peter Hutterer
for that approach. if the chromebooks are similar, restricting it to
tapping
Post by Peter Hutterer
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Peter Hutterer
2014-02-09 04:10:48 UTC
Permalink
Post by Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
generally for real touch screens (i.e. not touchpads) I think any
interpretation of the values should be on the client side, not in the input
library. There just isn't enough context to interpret it otherwise since
you're at least partially reliant on UI hints or other elements to make sure
you're emulating the right thing.

For specialized cases like having a permanent input region that maps into
semantic buttons (e.g. the button bar on the Android phones) this should IMO
be handled by the compositor.
Post by Eugen Friedrich
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
Yes, calibration is a required feature, I forgot to mention that since it's
already supported.

Cheers,
Peter
Post by Eugen Friedrich
What do you think?
Post by Peter Hutterer
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
I've been thinking about how to add a device configuration interface
to
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
specific, so it is independent of a classification or capabilities of
a
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
device. To the user it doesn't matter if we classify something as
touchpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
or as mouse, if middle mouse button emulation works that's the only
thing
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
them.
Aside from setting an item, there should be calls to get the current
value,
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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);
* {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"
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
* 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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
could be an API taking nfingers as argument as opposed to 3 different
calls.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
Likewise, they can take more than one value argument, e.g. middle
button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
a set of buttons for the trackstick. There's nothing to be configured
about
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area should move the pointer (I suggested that it shouldn't,
you
Post by Peter Hutterer
Post by Alexander E. Patrakov
suggested that it should, and both of us had valid arguments, so it
needs to
Post by Peter Hutterer
Post by Alexander E. Patrakov
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
if a hardware button reports that it is clicked, but there is no finger
in any
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
Post by Peter Hutterer
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
Post by Peter Hutterer
actually trigger a button, you need to start inside the button area -
which
Post by Peter Hutterer
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.
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
Post by Peter Hutterer
hide away. we already do something similar in the synaptics driver where
we
Post by Peter Hutterer
don't initialize software buttons for macbooks because they're not
designed
Post by Peter Hutterer
for that approach. if the chromebooks are similar, restricting it to
tapping
Post by Peter Hutterer
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Eugen Friedrich
2014-02-09 12:32:41 UTC
Permalink
Post by Peter Hutterer
Post by Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
generally for real touch screens (i.e. not touchpads) I think any
interpretation of the valthis should IMO
be handled by the compositorues should be on the client side, not in the
input
Post by Peter Hutterer
library. There just isn't enough context to interpret it otherwise since
you're at least partially reliant on UI hints or other elements to make sure
you're emulating the right thing.
Completely agree, active input elements which are drawn by some
application should be handled by this application.
Post by Peter Hutterer
For specialized cases like having a permanent input region that maps into
semantic buttons (e.g. the button bar on the Android phones) this should IMO
be handled by the compositor.
Yes this was the aim of my proposal. This would give a flexibility to
use different touch panel with different screens and put you permanent
buttons and slider wherever you like. Such cases are maybe only
important if you are building up a new devices but this configuration
possibility would add a big value for the libinput.
Post by Peter Hutterer
Post by Eugen Friedrich
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
Yes, calibration is a required feature, I forgot to mention that since it's
already supported.
Cheers,
Peter
Post by Eugen Friedrich
What do you think?
Post by Peter Hutterer
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
I've been thinking about how to add a device configuration interface
to
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
specific, so it is independent of a classification or capabilities of
a
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
device. To the user it doesn't matter if we classify something as
touchpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
or as mouse, if middle mouse button emulation works that's the only
thing
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
them.
Aside from setting an item, there should be calls to get the current
value,
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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);
* {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"
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
* 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.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
could be an API taking nfingers as argument as opposed to 3 different
calls.
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
Likewise, they can take more than one value argument, e.g. middle
button
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
a set of buttons for the trackstick. There's nothing to be configured
about
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area should move the pointer (I suggested that it shouldn't,
you
Post by Peter Hutterer
Post by Alexander E. Patrakov
suggested that it should, and both of us had valid arguments, so it
needs to
Post by Peter Hutterer
Post by Alexander E. Patrakov
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
Post by Peter Hutterer
Post by Alexander E. Patrakov
if a hardware button reports that it is clicked, but there is no finger
in any
Post by Peter Hutterer
Post by Alexander E. Patrakov
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
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
Post by Peter Hutterer
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal scrolling.
OK.
Post by Peter Hutterer
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
Post by Peter Hutterer
actually trigger a button, you need to start inside the button area -
which
Post by Peter Hutterer
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.
http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
Post by Peter Hutterer
Post by Alexander E. Patrakov
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
Post by Peter Hutterer
Post by Alexander E. Patrakov
right-click is to use two fingers.
I think that's a good example of machine-specific configuration that we
can
Post by Peter Hutterer
hide away. we already do something similar in the synaptics driver where
we
Post by Peter Hutterer
don't initialize software buttons for macbooks because they're not
designed
Post by Peter Hutterer
for that approach. if the chromebooks are similar, restricting it to
tapping
Post by Peter Hutterer
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Peter Hutterer
2014-02-09 21:57:52 UTC
Permalink
Post by Eugen Friedrich
Post by Peter Hutterer
Post by Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
generally for real touch screens (i.e. not touchpads) I think any
interpretation of the valthis should IMO
be handled by the compositorues should be on the client side, not in
the input
Post by Peter Hutterer
library. There just isn't enough context to interpret it otherwise since
you're at least partially reliant on UI hints or other elements to make sure
you're emulating the right thing.
Completely agree, active input elements which are drawn by some
application should be handled by this application.
Post by Peter Hutterer
For specialized cases like having a permanent input region that maps into
semantic buttons (e.g. the button bar on the Android phones) this should IMO
be handled by the compositor.
Yes this was the aim of my proposal. This would give a flexibility
to use different touch panel with different screens and put you
permanent buttons and slider wherever you like. Such cases are maybe
only important if you are building up a new devices but this
configuration possibility would add a big value for the libinput.
my main worry here is that the semantics of such buttons are unknown to
anyone but the compositor. libinput has _no_ semantics other than "here's
and area" but especially with direct-touch devices you get more complex
interactions to this. For example, let's say we have a defined button area
at the bottom of the screen:
- should the button trigger if the finger moved from the outside into the
area?
- should the button trigger if the finger left and re-entered the area?
- should the button trigger if the finger left the area?
-- oh, btw, now you need enter/leave events to notify the compositor
- should the button trigger if there is another finger within the area?
- should the button trigger if there was extensive movement between
press/release in the button area?
..

All these usually have fairly obvious answers from a UI perspective, but a
low-level library without semantic context would have to provide some matrix
to enable all of them or restrict itself to a set of the above. The latter
wouldn't be a problem, but we'd have to really see some good use-cases to
justify the extra complexity.

Cheers,
Peter
Dominic Jänichen
2014-02-18 16:33:53 UTC
Permalink
Post by Peter Hutterer
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.
<snip>
Post by Peter Hutterer
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).
Does that imply the following use case will be supported?

Being used to TP trackpoints, I am using the index finger outside the
button area (on a touchpad that doubles as one hardware button) and the
thumb to "click".
I'd expect to able to move the pointer with the index finger while
clicking, disregarding slight thumb movements while doing so.


This seems to very difficult to archieve (if at all) with the synaptics
driver; the points jumps widely, especially if the index finger is
removed from the touch pad immediately before clicking.

I can imagine that this boils down to having areas insensitive to motion,
but still working as softbuttons.

Dominic
Peter Hutterer
2014-02-18 22:52:21 UTC
Permalink
Post by Dominic Jänichen
Post by Peter Hutterer
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.
<snip>
Post by Peter Hutterer
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).
Does that imply the following use case will be supported?
Being used to TP trackpoints, I am using the index finger outside the
button area (on a touchpad that doubles as one hardware button) and the
thumb to "click".
I'd expect to able to move the pointer with the index finger while
clicking, disregarding slight thumb movements while doing so.
This seems to very difficult to archieve (if at all) with the synaptics
driver; the points jumps widely, especially if the index finger is
removed from the touch pad immediately before clicking.
I can imagine that this boils down to having areas insensitive to motion,
but still working as softbuttons.
The set of touchpad patches I sent out recently already handle this by
default. When the physical clickpad button is depressed, the driver picks
the finger that is pressing the button (sometimes guessing, but hey...).
That finger cannot control the pointer movement until the button is released
again.

In your specific use case, the driver would see two touchpoints and it will
select the one closer to the bottom edge as the pressing finger (i.e. your
thumb). The index finger can still move while the button is down.

Cheers,
Peter
Alexander E. Patrakov
2014-02-19 05:55:28 UTC
Permalink
Post by Peter Hutterer
The set of touchpad patches I sent out recently already handle this by
default. When the physical clickpad button is depressed, the driver picks
the finger that is pressing the button (sometimes guessing, but hey...).
That finger cannot control the pointer movement until the button is released
again.
In your specific use case, the driver would see two touchpoints and it will
select the one closer to the bottom edge as the pressing finger (i.e. your
thumb). The index finger can still move while the button is down.
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say
that it doesn't solve the whole problem. Here is what goes wrong with
the old synaptics driver by default and can be worked around with
AreaBottomEdge.

Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"

1. I move the right-hand index finger on the touchpad, thus moving the
pointer to the place where I want to click.

2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot remove
the right-hand finger: if I do that, while the contact area shrinks, its
center also moves, and the driver picks that up.

3. As I increase the pressure on the left-hand finger until the touchpad
clicks, the contact area increases. Unfortunately, its center moves,
too, and this can accumulate to ~2-3 pixels until it clicks.

The important point is that the bad thing happens before the hardware
button click, so the quoted solution totally misses the point.

So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual button
area is 100% there), or some very good filter that pays attention to
changes in pressure and filters any spurious movement (i.e. any movement
that is combined with significant pressure changes) out.

But hey, Sony in their new laptops started to ignore the problem under
Windows, too, so I think I just have to swallow this and/or use my
Bluetooth mouse.
--
Alexander E. Patrakov
Peter Hutterer
2014-02-20 05:14:22 UTC
Permalink
Post by Alexander E. Patrakov
Post by Peter Hutterer
The set of touchpad patches I sent out recently already handle this by
default. When the physical clickpad button is depressed, the driver picks
the finger that is pressing the button (sometimes guessing, but hey...).
That finger cannot control the pointer movement until the button is released
again.
In your specific use case, the driver would see two touchpoints and it will
select the one closer to the bottom edge as the pressing finger (i.e. your
thumb). The index finger can still move while the button is down.
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.
Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"
1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.
2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.
3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.
The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.
So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays
can you expand on the 100% comment here? is the touchpad too small for
anything else?
Post by Alexander E. Patrakov
attention to changes in pressure and filters any spurious movement
(i.e. any movement that is combined with significant pressure
changes) out.
But hey, Sony in their new laptops started to ignore the problem
under Windows, too, so I think I just have to swallow this and/or
use my Bluetooth mouse.
couple of comments here:
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.
the xorg synaptics driver has for historical reasons and portability a
different approach to finger tracking and some of the misbehaviours are
easier to fix now.

The proposed patches have a different approach to the above:
1 - would be recognised as touchpoint, since no other finger is active it is
designated as the pointer-moving touchpoint
2 - second finger recognised, but not assigned as pointer-moving. Movements
on that finger have no effect, unless 2-finger scrolling is triggered.
3 - no effect, finger is not moving

So really, the goal here is that whatever the motion we see in 2 and 3 is to
not go past the "trigger 2-finger scrolling" threshold.

I do have a set of patches not yet ported for the virtual buttons and they
add additional tracking, so that a finger that starts (and stays) inside a
softbutton area won't contribute to movements, but as you said above that
may not work with the vaio.

Cheers,
Peter
Alexander E. Patrakov
2014-02-20 06:21:53 UTC
Permalink
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
The set of touchpad patches I sent out recently already handle this by
default. When the physical clickpad button is depressed, the driver picks
the finger that is pressing the button (sometimes guessing, but hey...).
That finger cannot control the pointer movement until the button is released
again.
In your specific use case, the driver would see two touchpoints and it will
select the one closer to the bottom edge as the pressing finger (i.e. your
thumb). The index finger can still move while the button is down.
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.
Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"
1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.
2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.
3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.
The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.
So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays
can you expand on the 100% comment here? is the touchpad too small for
anything else?
The height of the touchpad is too small (the width is OK). See e.g.
Loading Image...

(Just to avoid confusion: I have a Sony Vaio Z23A4R, don't have a Sony
Vaio Duo 13, and don't have a Sony Vaio Pro 13. As for my accent on Sony
laptops, that's only because there is a Sony shop nearby.)
Post by Peter Hutterer
Post by Alexander E. Patrakov
attention to changes in pressure and filters any spurious movement
(i.e. any movement that is combined with significant pressure
changes) out.
But hey, Sony in their new laptops started to ignore the problem
under Windows, too, so I think I just have to swallow this and/or
use my Bluetooth mouse.
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.
OK, I will build this on my laptop from git later today.
Post by Peter Hutterer
the xorg synaptics driver has for historical reasons and portability a
different approach to finger tracking and some of the misbehaviours are
easier to fix now.
1 - would be recognised as touchpoint, since no other finger is active it is
designated as the pointer-moving touchpoint
2 - second finger recognised, but not assigned as pointer-moving. Movements
on that finger have no effect, unless 2-finger scrolling is triggered.
3 - no effect, finger is not moving
So really, the goal here is that whatever the motion we see in 2 and 3 is to
not go past the "trigger 2-finger scrolling" threshold.
Yes, I think we agree on that.
Post by Peter Hutterer
I do have a set of patches not yet ported for the virtual buttons and they
add additional tracking, so that a finger that starts (and stays) inside a
softbutton area won't contribute to movements, but as you said above that
may not work with the vaio.
Yes, I would like to see that on my Z23A4R (and it matches the Windows
default), but users of Duo 13 definitely would not want that enabled on
their laptops. As for Sony Vaio Pro 13, this feature won't hurt, but, as
I have already said, does not match the Windows default there.
--
Alexander E. Patrakov
Peter Hutterer
2014-02-20 06:42:59 UTC
Permalink
Post by Peter Hutterer
Post by Alexander E. Patrakov
Post by Peter Hutterer
The set of touchpad patches I sent out recently already handle this by
default. When the physical clickpad button is depressed, the driver picks
the finger that is pressing the button (sometimes guessing, but hey...).
That finger cannot control the pointer movement until the button is released
again.
In your specific use case, the driver would see two touchpoints and it will
select the one closer to the bottom edge as the pressing finger (i.e. your
thumb). The index finger can still move while the button is down.
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.
Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"
1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.
2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.
3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.
The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.
So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays
can you expand on the 100% comment here? is the touchpad too small for
anything else?
The height of the touchpad is too small (the width is OK). See e.g. http://www.blogcdn.com/www.engadget.com/media/2013/06/dsc00149-1370365891.jpg
(Just to avoid confusion: I have a Sony Vaio Z23A4R, don't have a
Sony Vaio Duo 13, and don't have a Sony Vaio Pro 13. As for my
accent on Sony laptops, that's only because there is a Sony shop
nearby.)
quite frankly, I think this touchpad is one where you (the user) would have
to get used to tap-and-drag and two-finger tapping or two-finger clicking
instead virtual button areas. I think that'd be a much better fit for a
touchpad like this.

Cheers,
Peter
Post by Peter Hutterer
Post by Alexander E. Patrakov
attention to changes in pressure and filters any spurious movement
(i.e. any movement that is combined with significant pressure
changes) out.
But hey, Sony in their new laptops started to ignore the problem
under Windows, too, so I think I just have to swallow this and/or
use my Bluetooth mouse.
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.
OK, I will build this on my laptop from git later today.
Post by Peter Hutterer
the xorg synaptics driver has for historical reasons and portability a
different approach to finger tracking and some of the misbehaviours are
easier to fix now.
1 - would be recognised as touchpoint, since no other finger is active it is
designated as the pointer-moving touchpoint
2 - second finger recognised, but not assigned as pointer-moving. Movements
on that finger have no effect, unless 2-finger scrolling is triggered.
3 - no effect, finger is not moving
So really, the goal here is that whatever the motion we see in 2 and 3 is to
not go past the "trigger 2-finger scrolling" threshold.
Yes, I think we agree on that.
Post by Peter Hutterer
I do have a set of patches not yet ported for the virtual buttons and they
add additional tracking, so that a finger that starts (and stays) inside a
softbutton area won't contribute to movements, but as you said above that
may not work with the vaio.
Yes, I would like to see that on my Z23A4R (and it matches the
Windows default), but users of Duo 13 definitely would not want that
enabled on their laptops. As for Sony Vaio Pro 13, this feature
won't hurt, but, as I have already said, does not match the Windows
default there.
Alexander E. Patrakov
2014-02-20 19:29:05 UTC
Permalink
Post by Alexander E. Patrakov
Post by Peter Hutterer
Post by Alexander E. Patrakov
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.
Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"
1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.
2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.
3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.
The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.
So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.
OK, I will build this on my laptop from git later today.
Just did this, but have not looked at the code yet. Tested with
xf86-input-libinput, thus had no chance to configure anything specific
to libinput. If this has any chance of yielding different results, I
will retest with Weston on Saturday.

Software versions:

* mtdev 1.1.4 (Gentoo)
* xorg-server 1.15.0 (Gentoo)
* libevdev from git, cf70d0
* libinput from git, 128f98 + your 19 patches
* xf86-input-libinput from git, 761603

Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows:

I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=mouse0 event3
B: PROP=5
B: EV=b
B: KEY=e520 10000 0 0 0 0
B: ABS=660800011000003

Pointer movement works, but it is too slow by default on this laptop.
That is, a VERY quick swipe (not expected during normal work and even
during games) from left to right is just enough to move the pointer
across the entire screen (1920x1080). Setting constant deceleration to
0.3 or 0.4 makes it more usable in terms of speed, but this might be my
personal preference, and I am not sure if the constant deceleration is
the correct knob here.

With the default constant deceleration (1.0), pointer movement is very
precise. It follows the finger equally well in all parts of the touchpad
and in all directions, as expected. I get no misplaced clicks.

With constant deceleration 0.3, this is not true. It works better in the
central part of the touchpad, but, when crossing the physical border
between the area for pointer movement (which is rough) and the area for
virtual buttons (which is smooth), it starts to behave like a dirty
mechanical mouse. Here is what I mean by that: hard to move the cursor
diagonally (i.e. there is a strong preference towards horizontal or
vertical movements), and the motion is uneven if I move the finger
slowly. The same applies to the top part of the touchpad, although there
is no sharp line where this appears.

In both cases, there is no spurious pointer movement when putting the
finger on the touchpad or removing it. I.e., points 2 and 3 are somehow
already dealt with.

Vertical two-finger scrolling works, but is way too sensitive both with
constant deceleration 1.0 and with 0.3.

Clicking works. If there are two fingers on the touchpad at the time of
clicking, it registers a right-click. As the touchpad cannot track more
than two touches, three-finger gestures don't work. OTOH, I have read
Documentation/input/multi-touch-protocol.txt: "Some devices identify
and/or track more contacts than they can report to the driver." I have
not yet tested whether this applies to my touchpad, and whether it uses
BTN_TOOL_TRIPLETAP.

Tapping and tap-and-drag are not usable. They require not tapping, but
knocking with force. So this points to the driver being "miscalibrated"
on the pressure axis. Can this also be the reason of the low x/y
sensitivity and "dirty mouse" feeling?

Can I provide any objective data that would allow better sensitivity
calibration by default on this device?
--
Alexander E. Patrakov
Peter Hutterer
2014-02-20 23:26:09 UTC
Permalink
Post by Alexander E. Patrakov
Post by Alexander E. Patrakov
Post by Peter Hutterer
Post by Alexander E. Patrakov
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.
Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
Option "AreaBottomEdge" "3500"
1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.
2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.
3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.
The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.
So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.
OK, I will build this on my laptop from git later today.
Just did this, but have not looked at the code yet. Tested with
xf86-input-libinput, thus had no chance to configure anything
specific to libinput. If this has any chance of yielding different
results, I will retest with Weston on Saturday.
libinput currently exposes no configuration interfaces, so the only
differences you may see is in pointer acceleration.
Post by Alexander E. Patrakov
* mtdev 1.1.4 (Gentoo)
* xorg-server 1.15.0 (Gentoo)
* libevdev from git, cf70d0
* libinput from git, 128f98 + your 19 patches
* xf86-input-libinput from git, 761603
I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=mouse0 event3
B: PROP=5
B: EV=b
B: KEY=e520 10000 0 0 0 0
B: ABS=660800011000003
Pointer movement works, but it is too slow by default on this
laptop. That is, a VERY quick swipe (not expected during normal work
and even during games) from left to right is just enough to move the
pointer across the entire screen (1920x1080). Setting constant
deceleration to 0.3 or 0.4 makes it more usable in terms of speed,
but this might be my personal preference, and I am not sure if the
constant deceleration is the correct knob here.
I have not yet looked into pointer-accel fine-tuning on the touchpad or in
xf86-input-libinput. What you're seeing is quite simliar to what I have here
- it's slow but not unusable. Sorry, just haven't focused on that yet by any
help would be appreciated.

I don't think deceleration is the right nob here, but I can't remember what
you need to tweak. Generally I try not to touch constant deceleration unless
the device is a high-resolution device that sends way too many events. If
you need to use a value 0..1 for CD then you're effectively using it to
speed things up, the term "deceleration" should hint that this may not work
perfectly :)
Post by Alexander E. Patrakov
With the default constant deceleration (1.0), pointer movement is
very precise. It follows the finger equally well in all parts of the
touchpad and in all directions, as expected. I get no misplaced
clicks.
With constant deceleration 0.3, this is not true. It works better in
the central part of the touchpad, but, when crossing the physical
border between the area for pointer movement (which is rough) and
the area for virtual buttons (which is smooth), it starts to behave
like a dirty mechanical mouse. Here is what I mean by that: hard to
move the cursor diagonally (i.e. there is a strong preference
towards horizontal or vertical movements), and the motion is uneven
if I move the finger slowly. The same applies to the top part of the
touchpad, although there is no sharp line where this appears.
In both cases, there is no spurious pointer movement when putting
the finger on the touchpad or removing it. I.e., points 2 and 3 are
somehow already dealt with.
Vertical two-finger scrolling works, but is way too sensitive both
with constant deceleration 1.0 and with 0.3.
that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to
push. 761603d..bee8989 now, please re-test that.
Post by Alexander E. Patrakov
Clicking works. If there are two fingers on the touchpad at the time
of clicking, it registers a right-click. As the touchpad cannot
track more than two touches, three-finger gestures don't work. OTOH,
I have read Documentation/input/multi-touch-protocol.txt: "Some
devices identify and/or track more contacts than they can report to
the driver." I have not yet tested whether this applies to my
touchpad, and whether it uses BTN_TOOL_TRIPLETAP.
run evtest or evemu-record against the device, that'll tell you. Note that I
haven't enabled the fake touch emulation for those devices yet, right now
BTN_TOOL* is only treated as a touch on single-touch devices.
so right now, you only get up to ABS_MT_SLOT maximum touchpoints.
Post by Alexander E. Patrakov
Tapping and tap-and-drag are not usable. They require not tapping,
but knocking with force. So this points to the driver being
"miscalibrated" on the pressure axis. Can this also be the reason of
the low x/y sensitivity and "dirty mouse" feeling?
that's a bit odd. I'd like to see an evemu-record output from that then.
Currently I ignore pressure completely, so any touch should be detected.
Post by Alexander E. Patrakov
Can I provide any objective data that would allow better sensitivity
calibration by default on this device?
Touchpad data is always subjective :) it depends on finger size,
conductivity and a whole bunch of other factors. what does help though is
having evemu recordings of certain events. They may still be subjective but
they're reproducible, allowing us to fine-tune based on a specific event
sequence and then go from there.

e.g. you can take a recording fo an example one-finger tap and then make
sure that that always produces a tap event. if you build up a database of
these events, you can cover events quite well for a multitude of devices and
users.

Cheers,
Peter
Alexander E. Patrakov
2014-02-22 07:49:06 UTC
Permalink
Post by Peter Hutterer
Touchpad data is always subjective :) it depends on finger size,
conductivity and a whole bunch of other factors. what does help though is
having evemu recordings of certain events. They may still be subjective but
they're reproducible, allowing us to fine-tune based on a specific event
sequence and then go from there.
e.g. you can take a recording fo an example one-finger tap and then make
sure that that always produces a tap event. if you build up a database of
these events, you can cover events quite well for a multitude of devices and
users.
OK. Attached are some sample recordings from my touchpad, while the
synaptics driver is in use (for visual feedback).

left-clicks.rec: 10 left clicks. Any pointer movement is not intended
and should be rejected by the driver.

move-and-double-tap{,2}.rec: contains finger movement to a certain
word on the screen, followed by double-tapping on that word. The
synaptics driver, however, converted one of these into a tap-and-drag.

move-tap-and-drag{,2,3}.rec: contains finger movement to a certain
word on the screen, followed by attempting to select a certain part of
it by tapping and dragging. In one case, contains a non-deliberate
vertical-movement error that led to selecting a line of text.

pretend-close-pidgin.rec: just an attempt to move the pointer to the
center f the close button of Pidgin.

pretend-close-pidgin-bad.rec: the same, but, upon removing the finger,
the synaptics driver picks up unwanted motion. Basically, the last
reported point before removing the finger should have been discarded
as invalid.

scroll-up.rec: scrolling the text up, 10 times.

swipe3-right: some three-finger swipes to the right on a touchpad that
can track only two fingers. Contains BTN_TOOL_TRIPLETAP.
--
Alexander E. Patrakov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec.tar.xz
Type: application/x-xz
Size: 38524 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140222/58ad9bd6/attachment-0001.bin>
Alexander E. Patrakov
2014-02-22 09:33:26 UTC
Permalink
Post by Peter Hutterer
Post by Alexander E. Patrakov
Vertical two-finger scrolling works, but is way too sensitive both
with constant deceleration 1.0 and with 0.3.
that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to
push. 761603d..bee8989 now, please re-test that.
The speed is now fixed indeed, but scrolling is now subject to the
same "dirty mouse" bug. See the "badscroll.rec" file in the attached
archive. It contains two scoll gestures - one down, and one up. The
driver has picked up only the beginning of the up-scroll (i.e. the
chromium window was not scrolled as far as I wanted, even though I
continued moving both fingers).
Post by Peter Hutterer
Post by Alexander E. Patrakov
Tapping and tap-and-drag are not usable. They require not tapping,
but knocking with force. So this points to the driver being
"miscalibrated" on the pressure axis. Can this also be the reason of
the low x/y sensitivity and "dirty mouse" feeling?
that's a bit odd. I'd like to see an evemu-record output from that then.
Currently I ignore pressure completely, so any touch should be detected.
Actually the first tap after the server start is detected reliably.
The problem only affects other taps. See the file "tap-libinput.rec"
in the attached archive.
--
Alexander E. Patrakov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec2.tar.xz
Type: application/x-xz
Size: 11020 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140222/9620787a/attachment-0001.bin>
Peter Hutterer
2014-03-26 07:17:49 UTC
Permalink
hey, sorry about the delay, I got moved to other stuff for a while and only
now just picked up libinput again.
Post by Alexander E. Patrakov
Post by Peter Hutterer
Post by Alexander E. Patrakov
Vertical two-finger scrolling works, but is way too sensitive both
with constant deceleration 1.0 and with 0.3.
that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to
push. 761603d..bee8989 now, please re-test that.
The speed is now fixed indeed, but scrolling is now subject to the
same "dirty mouse" bug. See the "badscroll.rec" file in the attached
archive. It contains two scoll gestures - one down, and one up. The
driver has picked up only the beginning of the up-scroll (i.e. the
chromium window was not scrolled as far as I wanted, even though I
continued moving both fingers).
I've looked at this and I think I know what you mean. I get a massive jump
down first, then a slight up only. Looking at the ./tools/event-debug output
from libinput it looks like the coordinates for downward scroll are massive
too (between 10 and 48), the upwards ones are hanging around the -3 to -4
mark. That would explain the different scrolling. however, that matches the
recordings.

I think what may be the problem here is the motion averaging between the
fingers. the driver currently takes the changed touchpoints and averages the
motion between the two for the actual scroll distance. this may slow down
slow scrolls, I'll need to run some tests on this.
Post by Alexander E. Patrakov
Post by Peter Hutterer
Post by Alexander E. Patrakov
Tapping and tap-and-drag are not usable. They require not tapping,
but knocking with force. So this points to the driver being
"miscalibrated" on the pressure axis. Can this also be the reason of
the low x/y sensitivity and "dirty mouse" feeling?
that's a bit odd. I'd like to see an evemu-record output from that then.
Currently I ignore pressure completely, so any touch should be detected.
Actually the first tap after the server start is detected reliably.
The problem only affects other taps. See the file "tap-libinput.rec"
in the attached archive.
I had a look at the recording files, mainly with the event-debug tools but
I'm struggingling to see the same issues. the tap recording has 6 touches,
some of which are taps, others are moves. I can spot three taps in there,
one in the middle somewhere, two towards the end and that seems to match the
recordings.

Cheers,
Peter
Peter Hutterer
2014-03-27 23:10:53 UTC
Permalink
(regarding slow scrolling)
I don't think so. I have tried to reproduce the bug by hand. It still
exists, but ./tools/event-debug still picks the scrolling up
correctly. I guess that this tool output already has the finger motion
averaging logic applied, so this speaks against your hypothesis. An
interesting observation that can ring some bells: Chromium picks up
the scroll events if and only if event-debug prints values whose
absolute value is greater than 10. Maybe the driver fails to combine
several small scroll events into a big one, or rounds the individual
scroll amounts instead of the accumulated value?
I have also tested regular (X/Y) pointer motion, and noticed the same
pattern. event-debug properly reports sub-pixel motion (i.e. prints
values below 1.0 if I move the finger slowly), but such multiple
sub-pixel motions are never added up into proper pointer events that
actually move the X pointer by at least one pixel.
yeah, I found that yesterday and it's a xf86-input-libinput issue.
Conversion to integers would just drop small values. I've pushed a fix to
use valuator masks with doubles now and that seems to fix the issue.
Try 1ab6637b56272bb5cef0568a785e2e5948e6b022.

Cheers,
Peter

Continue reading on narkive:
Loading...