Re: Plumbing explicit synchronization through the Linux ecosystem
On Thu, Mar 12, 2020 at 6:36 PM Jason Ekstrand wrote: > From the perspective of a Wayland compositor (I used to play in this > space), they'd love to implement the new explicit sync extension but > can't. Sure, they could wire up the extension, but the moment they go > to flip a client buffer to the screen directly, they discover that KMS > doesn't support any explicit sync APIs. So, yes, they can technically > implement the extension assuming the EGL stack they're running on has > the sync_file extensions but any client buffers which come in using > the explicit sync Wayland extension have to be composited and can't be > scanned out directly. As a 3D driver developer, I absolutely don't > want compositors doing that because my users will complain about > performance issues due to the extra blit. Maybe this is something for the Marketing Department to solve? Sell the extra processing that can be done during such extra blit as a feature? As a former user of a wide-gamut monitor that has no sRGB mode, and a gamer, I would definitely accept the extra step (color conversion, not "just a blit"!) between the application and the actual output. In fact, I have set up compicc just for this purpose. Games with poisonous oversaturated colors (because none of the game authors care about wide-gamut monitors) are worse than the same games affected by the very small performance penalty due to the conversion. We just need a Marketing Person to come up with a huge list of other cases where such compositing step is required for correctness, and declare that direct scanout is something that makes no sense in the present day, except possibly on embedded devices. Of course the above trolling does not solve the problem related to inability to be sure about the correct API usage. -- Alexander E. Patrakov CV: http://pc.cd/PLz7 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [systemd-devel] [ANNOUNCE] systemd v230
22.05.2016 13:33, Alexander E. Patrakov пишет: 22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет: Hi, systemd v230 has been tagged. Enjoy! CHANGES WITH 230: * Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with "uaccess" and are available to logged in users. Has this been discussed with Wayland developers? Framebuffer device access can possibly be abused to take screenshots and draw on top of the compositor in a Wayland-based environment. Impossibility for arbitrary applications to take screenshots was one of the design goals of Wayland, and this change breaks it. So, unless one of Wayland developers confirms that they are OK with it, please revert it and ask for a CVE. Sorry, I have to take this back. Attempting to grab video from /dev/fb0 here on Intel hardware, both under X and Weston, shows only an image from the first virtual console - i.e. not the actual session. Still, I would like someone else to confirm that this behaviour is not Intel-specific and cannot be circumvented by, say, ioctls on /dev/fb0. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [systemd-devel] [ANNOUNCE] systemd v230
22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет: Hi, systemd v230 has been tagged. Enjoy! CHANGES WITH 230: * Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with "uaccess" and are available to logged in users. Has this been discussed with Wayland developers? Framebuffer device access can possibly be abused to take screenshots and draw on top of the compositor in a Wayland-based environment. Impossibility for arbitrary applications to take screenshots was one of the design goals of Wayland, and this change breaks it. So, unless one of Wayland developers confirms that they are OK with it, please revert it and ask for a CVE. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: SynPS/2 Synaptics TouchPad firmware bug
2014-03-29 0:16 GMT+06:00 Alexander E. Patrakov patra...@gmail.com:
No problem, I just did that for you. See the attached patch. Seems to
work here, but I am not 100% sure, especially about the non-mt case.
It does prevent sudden pointer jumps to the bottom left corner of the
screen (survived a while round of the Harvest Honors game, something
that the original driver cound not do!), but I also get some click
attempts mistreated as right-clicks. Probably because there are in
fact some moments when the touchpad thinks that two fingers are on it.
And now rebased on top of your wip/clickpad-improvements branch (which
works otherwise). Note that now I can get a right-click both using a
software button area and using a two-finger tap. Is this intentional?
--
Alexander E. Patrakov
From 3af1ca9d2aed569a171f9323a95aa5ee4fe6d85e Mon Sep 17 00:00:00 2001
From: Alexander E. Patrakov patra...@gmail.com
Date: Fri, 28 Mar 2014 23:57:56 +0600
Subject: [PATCH] Detect and discard huge coordinate jumps on touchpads.
Such jumps are usually consequences of the touchpad firmware
failing to notice that a different finger is in fact touching the
touchpad. If not discarded, such events lead to sudden pointer
jumps into screen corners.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=76722
Signed-off-by: Alexander E. Patrakov patra...@gmail.com
---
src/evdev-mt-touchpad.c | 51 -
src/evdev-mt-touchpad.h | 3 +++
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index de7a7e1..9cb2531 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -32,6 +32,7 @@
#define DEFAULT_MIN_ACCEL_FACTOR 0.16
#define DEFAULT_MAX_ACCEL_FACTOR 1.0
#define DEFAULT_HYSTERESIS_MARGIN_DENOMINATOR 700.0
+#define DEFAULT_JUMP_DETECTION_DENOMINATOR 8.0
static inline int
tp_hysteresis(int in, int center, int margin)
@@ -187,6 +188,48 @@ tp_end_touch(struct tp_dispatch *tp, struct tp_touch *t)
tp-queued |= TOUCHPAD_EVENT_MOTION;
}
+static inline void
+tp_disrupt_touch(struct tp_dispatch *tp, struct tp_touch *t)
+{
+ if (t-state == TOUCH_NONE)
+ return;
+
+ tp_end_touch(tp, t);
+ t-state = TOUCH_DISRUPT;
+}
+
+static inline void
+tp_undisrupt_touch(struct tp_dispatch *tp, struct tp_touch *t)
+{
+ if (t-state != TOUCH_DISRUPT)
+ return;
+
+ tp_begin_touch(tp, t);
+}
+
+static inline void
+tp_detect_jumps(struct tp_dispatch *tp,
+ struct tp_touch *t)
+{
+ /* Motivation: https://bugs.freedesktop.org/show_bug.cgi?id=76722 */
+
+ struct tp_motion *oldpos;
+ int dx, dy;
+
+ if (t-history.count == 0)
+ return;
+
+ /* This is called before tp_motion_history_push(),
+ so the latest historical datum is at offset 0.
+ */
+ oldpos = tp_motion_history_offset(t, 0);
+ dx = abs(t-x - oldpos-x);
+ dy = abs(t-y - oldpos-y);
+
+ if (dx tp-jump_threshold || dy tp-jump_threshold)
+ tp_disrupt_touch(tp, t);
+}
+
static double
tp_estimate_delta(int x0, int x1, int x2, int x3)
{
@@ -353,7 +396,8 @@ tp_unpin_finger(struct tp_dispatch *tp, struct tp_touch *t)
t-pinned.state = PIN_STATE_NONE;
- if (t-state != TOUCH_END tp-nfingers_down == 1)
+ if (t-state != TOUCH_END t-state != TOUCH_DISRUPT
+tp-nfingers_down == 1)
t-is_pointer = true;
}
@@ -417,6 +461,7 @@ tp_process_state(struct tp_dispatch *tp, uint32_t time)
} else if (!t-dirty)
continue;
+ tp_detect_jumps(tp, t);
tp_motion_hysteresis(tp, t);
tp_motion_history_push(t);
@@ -447,6 +492,8 @@ tp_post_process_state(struct tp_dispatch *tp, uint32_t time)
if (!t-dirty)
continue;
+ tp_undisrupt_touch(tp, t);
+
if (t-state == TOUCH_END) {
t-state = TOUCH_NONE;
t-fake = false;
@@ -742,6 +789,8 @@ tp_init(struct tp_dispatch *tp,
tp-hysteresis.margin_y =
diagonal / DEFAULT_HYSTERESIS_MARGIN_DENOMINATOR;
+ tp-jump_threshold = diagonal / DEFAULT_JUMP_DETECTION_DENOMINATOR;
+
if (tp_init_scroll(tp) != 0)
return -1;
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index fa4d932..70a9bb9 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -43,6 +43,7 @@ enum touch_state {
TOUCH_NONE = 0,
TOUCH_BEGIN,
TOUCH_UPDATE,
+ TOUCH_DISRUPT,
TOUCH_END
};
@@ -147,6 +148,8 @@ struct tp_dispatch {
int32_t margin_y;
} hysteresis;
+ int32_t jump_threshold;
+
struct motion_filter *filter;
struct {
--
1.8.5.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: SynPS/2 Synaptics TouchPad firmware bug
2014-03-29 0:16 GMT+06:00 Alexander E. Patrakov patra...@gmail.com: I also get some click attempts mistreated as right-clicks. Probably because there are in fact some moments when the touchpad thinks that two fingers are on it. Recorded, verified that it is unrelated to my patch, reported as https://bugs.freedesktop.org/show_bug.cgi?id=76760 -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
2014-02-21 5:26 GMT+06:00 Peter Hutterer peter.hutte...@who-t.net: On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote: 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). 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 rec2.tar.xz Description: application/xz ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
2014-02-21 5:26 GMT+06:00 Peter Hutterer peter.hutte...@who-t.net:
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
rec.tar.xz
Description: application/xz
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
20.02.2014 12:21, I wrote: 20.02.2014 11:14, Peter Hutterer wrote: On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: 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 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. 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 1 0 0 0 0 B: ABS=66080001103 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
Re: [RFC] libinput configuration interface
19.02.2014 04:52, Peter Hutterer wrote: 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fwd: [GSoC2014] Call for projects ideas and mentors
Martin Peres wrote: Re-send to include the wayland and mesa mailing lists. Sorry for the noise Original Message Subject: [GSoC2014] Call for projects ideas and mentors Date: Thu, 06 Feb 2014 01:03:05 +0100 From: Martin Peres martin.pe...@free.fr To: dri-de...@lists.freedesktop.org dri-de...@lists.freedesktop.org, xorg-de...@lists.x.org, x...@lists.x.org, nouveau nouv...@lists.freedesktop.org Hi, fellow graphics stack developers, Now that FOSDEM is over, it is time to think about the Google Summer of Code 2014! If you would like to propose a project for the GSoC 2014, please write your proposals at [1], before the 14th of February, in order to increase our chances of being an accepted organization. If you simply would potentially be interested in being a mentor, please also contact me as Google wants to have an estimate of the number of potential mentors we would have. I think that a possible project for someone would be to implement the functionality in libinput (or possibly via uinput) where a fingerprint reader could act as a scroll wheel for the touchpad. This functionality is common on Windows laptops, but completely missing in the Linux input stack. Yes, alternative scroll methods exist, so this is low-priority. One complication would be to ensure that the primary (authentication-related) functionality of the fingerprint reader is preserved. Note: I am not a student, and won't qualify as a mentor, either. So this is just an abstract idea for somebody to pick up. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
2014-02-03 Peter Hutterer peter.hutte...@who-t.net:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not device
specific, so it is independent of a classification or capabilities of a
device. To the user it doesn't matter if we classify something as touchpad
or as mouse, if middle mouse button emulation works that's the only thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads on
them.
Aside from setting an item, there should be calls to get the current value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to adjust for
hw-specific quirks. Such as defining which pressure makes up a tap, etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part of it
is
a set of buttons for the trackstick. There's nothing to be configured about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement in the
softbutton area should move the pointer (I suggested that it shouldn't, you
suggested that it should, and both of us had valid arguments, so it needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
if a hardware button reports that it is clicked, but there is no finger in
any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click (would
be my preference), treat this as left click (current situation with the
synaptics driver, and I guess some people would prefer this).
tbh, I'm not planning to support every potential option under the sun.
There's a fine and rather blurry line between what is a preference and what
is merely configuration because we can't commit to a single default. I'd
rather have less configuration options and support those well and do the
synaptics approach of supporting everything but being quite bad at how the
various options interact.
To extend this thought, even the list above is probably too detailed.
IMO tapping should just be a left, right, middle configuration for 1, 2, 3
fingers. Enabling/disabling tapping is a valid configuration but custom
button mapping is excessive (clickfinger is the same).
Likewise, there should be only one scroll method at a time, and one option
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal
Re: [RFC] libinput configuration interface
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not device
specific, so it is independent of a classification or capabilities of a
device. To the user it doesn't matter if we classify something as touchpad
or as mouse, if middle mouse button emulation works that's the only thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads on
them.
Aside from setting an item, there should be calls to get the current value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping configuration
could be an API taking nfingers as argument as opposed to 3 different calls.
Likewise, they can take more than one value argument, e.g. middle button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to adjust for
hw-specific quirks. Such as defining which pressure makes up a tap, etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part of it is
a set of buttons for the trackstick. There's nothing to be configured about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement in the
softbutton area should move the pointer (I suggested that it shouldn't, you
suggested that it should, and both of us had valid arguments, so it needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button clickpad
if a hardware button reports that it is clicked, but there is no finger in any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click (would
be my preference), treat this as left click (current situation with the
synaptics driver, and I guess some people would prefer this).
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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] What use do swap interval 1 and OML_sync_control divisor and remainder have?
[Just for the sake of argument] 2014-01-28 Pekka Paalanen ppaala...@gmail.com: Hi Ian and Jason On Mon, 27 Jan 2014 12:26:23 -0700 Ian Romanick i...@freedesktop.org wrote: There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. I would hope that no video player will use swap interval as a means of target timing, because the buffer queueing protocol I'm planning is supposed to be superior for accurately timed video presentation. The protocol will also be usable with EGL provided content, if the EGL implementation can cope with buffers being reserved by the display server for longer than usual. One more argument would be that video players actually don't want 30fps here, and do that only because of constrained resources. Every Smart TV sold nowadays has the motion-interpolation feature, which is (unlike frame-doubling, and at least from the viewpoint of some people) the proper way to display low-fps content on high-fps panels. PC-based video players don't have this feature because nobody so far has written the code that works on anything else than NVidia GPUs. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Authorized clients
2014/1/3 Maarten Baert maarten-ba...@hotmail.com: So far your protocol sounded secure, but I think this is where it breaks down. You're leaving the Wayland server open to a confused deputy attack, and also a social engineering attack. And also please consider the following hammer-based attack. A piece of malware could repeatedly try to launch something privileged. It looks like this. A polkit agent dialog appears, which is modal in most cases. The user says No. The dialog immediately appears again. The user says No. The dialog appears until the user authorizes the malware to do its bad thing. Of course this is not specific to Wayland or Weston, please run this piece of pseudo-malware to see what I mean: while ! pkexec bash ; do echo Too bad ; done So my opinion is that polkit dialogs should be avoided, or should have some protection against this. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and Weston 1.3 releases are out
Kristian Høgsberg wrote: Plans for 1.4 We're going to try something new for 1.4 - we'll do an alpha release a month before the scheduled release. I'm looking at Jan 15, 2014 as the release date for 1.4.0, and we'll do an alpha release on Dec 16. The motivation here is to get a snapshot out a bit earlier so we can start testing earlier and hopefully uncover bugs earlier. In the 1.3 cycle we did RC1 a week before the expected release date and ended up with a lot of bugs and no time to fix them. For 1.4 the hope is that the alpha release will let us discover those bugs while we still have month to fix them. After the alpha we'll start to slow down development, but there'll still be room for pulling in minor or low-risk features. We'll start the RCs on Jan 2, at which point we'll go into bug fix only mode. Here's my (probably incomplete) list of features that I think we can do for 1.4: - Moving subsurface and input methods into wayland. - Jasons decorations work. - Jasons surface/view split. - logind changes from David. - Output cloning - wl_shm buffer truncate exploit fix from Neil - eglSwapInterval(0) (Neil) - Nested wl_buffer pass-through (Neil) - Touch grabs to enable touch-to-focus (Neil) - Default pointer grab patch from Giulio - Use gstreamer or libva helper library instead of direct libva use for weston encoding. - wl_subsurface scaling. It is sad to see that clickpad support is not even on the list. Is there any understanding how it should be done? -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: Sony clickpad support
its center, thus resulting in a misplaced click unless movements in the button area are ignored). Your arguments for the opposite are also valid, that's why a user-configurable preference is a must. The real question is about the defaults. I think that, where possible, the default behaviour of native-platform (Windows, Chrome OS, Mac OS X) touchpad drivers should be copied, so that people who dual-boot don't have to learn two interaction models (e.g. by default, windows ignores movement in this area, linux doesn't is always a bug in linux, even if the user is not happy with the windows default). And this is where the X11 synaptics driver fails. Just for the record, a big please: don't use its defaults (which are not sufficiently device-specific anyway) in discussions of what should be done by default. I won't be surprised if the Windows driver for your touchpad also ignores movements in button areas - please retest if that's not too much burden for you. If it doesn't ignore movements in the button area, then we need yet another interaction model in evdev-touchpad.c that matches your default, please notify me and send /proc/bus/input/devices if it is indeed the case. don't get me wrong, I'm not saying that your approach is wrong. what I am arguing for is that we need some clear plan of how we are going to support all the quirky features that we need to eventually support. I am trying to at least build a list of these, but it'll take me a few more days I think. Yes, there surely is a need to get a clear plan how normal touchpads, weird touchpads and on-screen keyboards are going to be supported in the future. I have no problem carrying the patches on my laptop. However, also I think that there is no reason to delay support for Sony clickpads only due to the need of this plan, even if my approach is wrong (but please do look at the code). We can always move the code or reimplement the functionality elsewhere later. I will have no problem with my code being ripped out later due to the new plan. From any wayland application viewpoint, now, any touchpad is just a mouse. My patches don't change this and don't introduce new interfaces, so there is no way that an application can get a dependency on them, and no need to support them forever. If any application would have to be rewritten due to the new plan, then this is equally true both with and without my patches. And the amount of work needed to implement the new plan is the same: write the plan, implement the desired touches-to-everything-else conversion logic in the new place, rip out the entire evdev-touchpad.c file. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: Sony clickpad support
2013/8/15 Peter Hutterer peter.hutte...@who-t.net: one of the things that should be done is to figure out _where_ features such as this are going to be handled. In the compositor, the compositor's input module, on the client side, ... ? I'm trying to figure out how to handle this correctly, but don't have much to show here just yet. For example, wl_pointer only has a button event, which means that a client cannot differ between a tap and a button click. no doubt this should be in a piece of shared code, but right now it's not quite sure what can be shared where yet. FWIW, I don't have a self-consistent opinion on this, but I have a clickpad that needs my patch or something similar :) It may sound too trivial, but here are the conflicting arguments to consider. 1. Consistency. I find the situation quite similar to that with on-screen keyboards (or maybe input methods). I am saying that separately, because on GUADEC an opinion was expressed by me and confirmed by Keith Packard that on-screen keyboards are not necessarily input methods. Indeed, an on-screen keyboard converts a sequence of touches or pointer clicks into a series of correctly-timed key up/down events that you can (ideally) use to play Quake or enter text, while traditional input methods only produce text. OTOH Caribou with its long-press-to-get-accents mode can't get timings right. And here and now we have a mechanism that converts touchpad touches into a series of pointer events and button clicks - i.e. another case of event converter. It would look wrong if these two use cases for event converters have inconsistent designs. 2. Complexity. Maybe off-topic: yesterday in a shop I also saw a bluetooth keyboard with a built-in touchpad (from a local manufacturer, looks quite similar to Rapoo E9080 but has bluetooth), and bought it for use as a remote controller for the media center. The peculiar thing was that the touchpad doubles as a numpad, i.e. has painted markings on it, and a touch-based virtual switch that puts the touchpad either in the touchpad mode or in the numpad mode. This particular device does the necessary interpretation of touches in hardware, i.e. the kernel emits pointer relative events and button presses or key events without any special drivers. But I won't be surprised if new devices with painted markings around virtual keys appear on the market that will also need to be decoded in software. So the software that converts touches on specially-marked surfaces into their device-specific intended meaning will likely get more complex and weird in the future. Just like input methods. 3. Compatibility. There is already a lot of software (e.g. weston-terninal and all gtk+ apps) that expects a pointer-like interface when operated with a touchpad. We can't just break it. 4. The need to show a pointer. There is a notion of the global pointer position that needs to be maintained in the compositor that is used with a touchpad. Due to the need to show this pointer, one can't entirely punt touchpad support to applications. And we can't punt only gestures and quirks to applications, as on Sony touchpads there is an area where finger movements should be ignored for the purpose of moving the pointer, and the pointer is a thing that belongs to a compositor. 5. Artificial limitations. Like it or not, there will be software in the future that wants to get the exact finger positions and not the interpreted events. E.g. software that is used to configure and calibrate the touchpad, games, or software that wants to implement custom app-specific gestures. That's exactly like games that want raw keypresses and not text constructed by the input method. However, in my opinion, people want their hardware supported now, and will not wait for an architecturally-correct solution (that can be added later). For now, anyway, a touchpad is just something that sends wl_pointer events, and if it continues to be that way, applications won't need to be changed. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: Sony clickpad support
2013/8/12 David Herrmann dh.herrm...@gmail.com: The implementation looks quite nice. I will not comment on the code individually, though. I'd really like to see a libtouchpad which implements all that logic. Once we start adding device drivers to weston, we will end up with a mess where we have to port it to each compositor we write. If gnome-shell becomes a compositor, it needs to implement this again. libxkbcommon already abstracted the keyboard handling. Why not do the same for touchpads? The wl_touch interface to weston is already standardized, so all this library needs to provide is a state-machine that converts evdev events into something similar to wl_touch. It's currently on my TODO list, so feel free to ignore it. But imho we should try to keep user-space input drivers separate to allow reuse and uniform configurations. If you set up a git repository for libtouchpad, I will help with the code there. OTOH I don't yet agree with the use of wl_touch as the output of such library. In the wl_touch documentation, touchscreens are mentioned, not touchpads. With touchpads, people often talk about moving the pointer, hovering, clicking and scrolling (even though scrolling is a gesture), and that fits better under wl_pointer. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] weston: Sony clickpad support
This patch series adds support to weston for a special type of touchpads found in some laptops. These touchpads contain one physical button that covers the whole surface of the touchpad. Unlike the well-known Apple touchpad, these touchpads have markings painted on them, that designate virtual button areas. So the user interaction is quite different from one gets from Apple touchpads. +---+ |\/\/\/\/\/\/\/\/\/\/\/\/\/\| |/\/\/\/\/\/\/\/\/\/\/\/\/\/| |\/\/\/\/\/\/\/\/\/\/\/\/\/\| |/\ Cursor-moving area /\/| |\/\/\/\/\/\/\/\/\/\/\/\/\/\| |/\/\/\/\/\/\/\/\/\/\/\/\/\/| |\/\/\/\/\/\/\/\/\/\/\/\/\/\| +---+ -- painted line | Left | Right | | virtual| virtual| | button | button | +-+-+ ^ | painted line E.g., currently, in order to get a right-click on such clickpad, one has to click anywhere with two fingers. This is, however, inappropriate for touchpads I am talking about. See: one needs to drag something, he places a finger on the upper part of the touchpad surface (on the part of surface designated for moving the cursor), then places another finger into the left half of the button area, clicks with the intention to move the first finger. However, what he currently gets is a right-click. Also, if one wants to make a right click, he places his finger into the right half of the button area, clicks, but currently gets a left click. In other words, the touchpad is unusable for users that are accustomed to the way the interaction with the touchpad is done in Windows. I have implemented the interaction model that looks more like what one gets in Windows. In order to do so, I had to refactor the existing code a bit and add support for multitouch protocol to evdev-touchpad.c. Tested all of this on my Sony VAIO VPC-Z23A4R laptop. Here is what works: * Moving the cursor by moving the finger in the cursor-moving area of the touchpad. * Not moving the cursor if one moves the finger in the virtual button area. * Tap-to-click. * Tap-and-drag gesture (unreliable). * Left and right virtual buttons. * Dragging, as explaining above. * Insensitivity to bad clicks (those outside the designated button area). * Two-finger scrolling. ...i.e. the touchpad is now quite usable. Zoom gestures are not implemented, though. I have also added autodetection of the interaction model based on the laptops with clickpads that GUADEC participants brought with themselves. Result: the current interaction model is valid only for Apple and Chromebook Pixel laptops, for everyone else the alternative model in this patch is needed because there are buttons painted on the clickpad. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/8] evdev-touchpad: Split the reset logic
From: Alexander E. Patrakov patra...@gmail.com
In old code, the reset both cleared the (global) motion history and
invalidated some state associated with (the) touch point. In the
multitouch case, there is still the global motion history that may need
to be cleared, and there are potentially many touch points that are
certainly not appropriate to invalidate at once. So copy-paste the
logic in order to be able to separate these two kinds of actions as
needed.
---
src/evdev-touchpad.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index 35be921..6646896 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -102,8 +102,6 @@ struct touchpad_dispatch {
double min_accel_factor;
double max_accel_factor;
- int reset;
-
struct {
bool enable;
@@ -417,13 +415,10 @@ touchpad_update_state(struct touchpad_dispatch *touchpad,
uint32_t time)
int center_x, center_y;
double dx = 0.0, dy = 0.0;
- if (touchpad-reset ||
- touchpad-last_finger_state != touchpad-finger_state) {
- touchpad-reset = 0;
+ if (touchpad-last_finger_state != touchpad-finger_state) {
touchpad-motion_count = 0;
touchpad-hw_abs.x_valid = touchpad-hw_abs.y_valid = false;
touchpad-hw_abs.is_moving = false;
- /* XXX what about is_pressed? */
touchpad-last_finger_state = touchpad-finger_state;
@@ -511,7 +506,8 @@ on_release(struct touchpad_dispatch *touchpad)
{
touchpad-hw_abs.has_moved = touchpad-hw_abs.is_pressed = false;
- touchpad-reset = 1;
+ touchpad-hw_abs.x_valid = touchpad-hw_abs.y_valid = false;
+ touchpad-hw_abs.is_moving = false;
push_fsm_event(touchpad, FSM_EVENT_RELEASE);
}
@@ -589,7 +585,11 @@ process_key(struct touchpad_dispatch *touchpad,
case BTN_TOOL_AIRBRUSH:
case BTN_TOOL_MOUSE:
case BTN_TOOL_LENS:
- touchpad-reset = 1;
+ /* The reset-logic below was copied without understanding
+* and may be inappropriate */
+ touchpad-motion_count = 0;
+ touchpad-hw_abs.x_valid = touchpad-hw_abs.y_valid = false;
+ touchpad-hw_abs.is_moving = false;
break;
case BTN_TOOL_FINGER:
if (e-value)
@@ -711,8 +711,6 @@ touchpad_init(struct touchpad_dispatch *touchpad,
touchpad-filter = accel;
/* Setup initial state */
- touchpad-reset = 1;
-
memset(touchpad-motion_history, 0, sizeof touchpad-motion_history);
touchpad-motion_index = 0;
touchpad-motion_count = 0;
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 5/8] evdev-touchpad: Introduced the notion of interaction model
From: Alexander E. Patrakov patra...@gmail.com
Different hardware can be interacted with differently. So far, there is
some code for simple trackpads and for buttonpads. For buttonpads,
currently the FSM is disabled and the right click is emulated through
two-finger click. This is OK for Apple hardware, but not for Sony. A
Sony-specific interaction model will be introduced later.
---
src/evdev-touchpad.c | 47 ++-
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index a9b21b8..1ed2dbb 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -45,7 +45,12 @@ enum touchpad_model {
TOUCHPAD_MODEL_SYNAPTICS,
TOUCHPAD_MODEL_ALPS,
TOUCHPAD_MODEL_APPLETOUCH,
- TOUCHPAD_MODEL_ELANTECH
+ TOUCHPAD_MODEL_ELANTECH,
+};
+
+enum interaction_model {
+ INTERACTION_MODEL_SIMPLE = 0,
+ INTERACTION_MODEL_APPLE,
};
struct touchpad_model_spec {
@@ -95,6 +100,7 @@ struct touchpad_dispatch {
struct evdev_device *device;
enum touchpad_model model;
+ enum interaction_model interaction_model;
int finger_state;
int last_finger_state;
@@ -103,8 +109,6 @@ struct touchpad_dispatch {
double max_accel_factor;
struct {
- bool enable;
-
struct wl_array events;
enum fsm_state state;
struct wl_event_source *timer_source;
@@ -163,6 +167,28 @@ get_touchpad_model(struct evdev_device *device)
}
static void
+configure_interaction_model(struct touchpad_dispatch *touchpad)
+{
+ unsigned long prop_bits[INPUT_PROP_MAX];
+
+ touchpad-interaction_model = INTERACTION_MODEL_SIMPLE;
+
+ ioctl(touchpad-device-fd, EVIOCGPROP(sizeof(prop_bits)), prop_bits);
+ if (!TEST_BIT(prop_bits, INPUT_PROP_BUTTONPAD))
+ return;
+
+ switch (touchpad-model) {
+ case TOUCHPAD_MODEL_APPLETOUCH:
+ touchpad-interaction_model = INTERACTION_MODEL_APPLE;
+ break;
+ default:
+ weston_log(Found a buttonpad of unknown type, assuming
Apple-style\n);
+ touchpad-interaction_model = INTERACTION_MODEL_APPLE;
+ break;
+ }
+}
+
+static void
configure_touchpad_pressure(struct touchpad_dispatch *touchpad,
int32_t pressure_min, int32_t pressure_max)
{
@@ -293,7 +319,7 @@ process_fsm_events(struct touchpad_dispatch *touchpad,
uint32_t time)
enum fsm_event *pevent;
enum fsm_event event;
- if (!touchpad-fsm.enable)
+ if (touchpad-interaction_model == INTERACTION_MODEL_APPLE)
return;
if (touchpad-fsm.events.size == 0)
@@ -387,7 +413,7 @@ push_fsm_event(struct touchpad_dispatch *touchpad,
{
enum fsm_event *pevent;
- if (!touchpad-fsm.enable)
+ if (touchpad-interaction_model == INTERACTION_MODEL_APPLE)
return;
pevent = wl_array_add(touchpad-fsm.events, sizeof event);
@@ -578,7 +604,8 @@ process_key(struct touchpad_dispatch *touchpad,
case BTN_FORWARD:
case BTN_BACK:
case BTN_TASK:
- if (!touchpad-fsm.enable e-code == BTN_LEFT
+ if (touchpad-interaction_model == INTERACTION_MODEL_APPLE
+ e-code == BTN_LEFT
touchpad-finger_state == TOUCHPAD_FINGERS_TWO)
code = BTN_RIGHT;
else
@@ -667,12 +694,9 @@ touchpad_init(struct touchpad_dispatch *touchpad,
struct weston_motion_filter *accel;
struct wl_event_loop *loop;
- unsigned long prop_bits[INPUT_PROP_MAX];
struct input_absinfo absinfo;
unsigned long abs_bits[NBITS(ABS_MAX)];
- bool has_buttonpad;
-
double width;
double height;
double diagonal;
@@ -682,9 +706,7 @@ touchpad_init(struct touchpad_dispatch *touchpad,
/* Detect model */
touchpad-model = get_touchpad_model(device);
-
- ioctl(device-fd, EVIOCGPROP(sizeof(prop_bits)), prop_bits);
- has_buttonpad = TEST_BIT(prop_bits, INPUT_PROP_BUTTONPAD);
+ configure_interaction_model(touchpad);
/* Configure pressure */
ioctl(device-fd, EVIOCGBIT(EV_ABS, sizeof(abs_bits)), abs_bits);
@@ -746,7 +768,6 @@ touchpad_init(struct touchpad_dispatch *touchpad,
}
/* Configure */
- touchpad-fsm.enable = !has_buttonpad;
return 0;
}
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 6/8] evdev-touchpad: Made hw_abs an array
From: Alexander E. Patrakov patra...@gmail.com
In the non-multitouch case, the 0th entry tracks motion just as the old
scalar hw_abs. In the multitouch case, there will be one entry for each
slot, and relevant_touch is used to select which one is motion-tracked.
---
src/evdev-touchpad.c | 146 +++
1 file changed, 102 insertions(+), 44 deletions(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index 1ed2dbb..01c52aa 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -51,6 +51,7 @@ enum touchpad_model {
enum interaction_model {
INTERACTION_MODEL_SIMPLE = 0,
INTERACTION_MODEL_APPLE,
+ INTERACTION_MODEL_SONY,
};
struct touchpad_model_spec {
@@ -103,6 +104,8 @@ struct touchpad_dispatch {
enum interaction_model interaction_model;
int finger_state;
int last_finger_state;
+ int slot;
+ int relevant_touch;
double constant_accel_factor;
double min_accel_factor;
@@ -114,6 +117,7 @@ struct touchpad_dispatch {
struct wl_event_source *timer_source;
} fsm;
+ /* the extra dummy slot is used for out-of-range slots reported by
mtdev */
struct {
int32_t x;
int32_t y;
@@ -123,7 +127,7 @@ struct touchpad_dispatch {
bool is_moving;
bool is_pressed;
- } hw_abs;
+ } hw_abs[MAX_SLOTS + 1];
bool has_moved;
uint16_t touch_state;
@@ -436,29 +440,80 @@ fsm_timout_handler(void *data)
return 1;
}
+static bool
+is_valid_touch(struct touchpad_dispatch *touchpad, int slot)
+{
+ if (!touchpad-hw_abs[slot].x_valid)
+ return false;
+ if (!touchpad-hw_abs[slot].y_valid)
+ return false;
+ if (!touchpad-hw_abs[slot].is_pressed)
+ return false;
+ return true;
+}
+
static void
touchpad_update_state(struct touchpad_dispatch *touchpad, uint32_t time)
{
+ int i;
int motion_index;
int center_x, center_y;
double dx = 0.0, dy = 0.0;
/* For multitouch case, this will be a bitmask */
- uint16_t touch_state = touchpad-hw_abs.is_pressed;
- if (touch_state !touchpad-touch_state)
+ uint16_t touch_state = 0;
+ int last_valid_touch = -1;
+ int relevant_touch = touchpad-relevant_touch;
+ bool reset_motion = false;
+
+ for (i = 0; i MAX_SLOTS; i++)
+ if (is_valid_touch(touchpad, i)) {
+ touch_state |= 1 i;
+ last_valid_touch = i;
+ }
+
+ if (touch_state !touchpad-touch_state) {
push_fsm_event(touchpad, FSM_EVENT_TOUCH);
+ reset_motion = true;
+ }
+
if (!touch_state touchpad-touch_state) {
push_fsm_event(touchpad, FSM_EVENT_RELEASE);
touchpad-has_moved = false;
+ reset_motion = true;
}
+ if (touch_state touchpad-touch_state
+ !(touch_state touchpad-touch_state)) {
+ push_fsm_event(touchpad, FSM_EVENT_RELEASE);
+ push_fsm_event(touchpad, FSM_EVENT_TOUCH);
+ touchpad-has_moved = false;
+ reset_motion = true;
+ }
+
+
+ if (relevant_touch != -1 !(touch_state (1 relevant_touch))) {
+ reset_motion = true;
+ relevant_touch = -1;
+ }
+ if (relevant_touch == -1)
+ relevant_touch = last_valid_touch;
+
+ if (touchpad-last_finger_state != touchpad-finger_state)
+ reset_motion = true;
+
touchpad-touch_state = touch_state;
+ touchpad-last_finger_state = touchpad-finger_state;
+ touchpad-relevant_touch = relevant_touch;
- if (touchpad-last_finger_state != touchpad-finger_state) {
+ if (reset_motion) {
touchpad-motion_count = 0;
- touchpad-hw_abs.x_valid = touchpad-hw_abs.y_valid = false;
- touchpad-hw_abs.is_moving = false;
+ if (touchpad-interaction_model != INTERACTION_MODEL_SONY) {
+ touchpad-hw_abs[0].x_valid = false;
+ touchpad-hw_abs[0].y_valid = false;
+ touchpad-hw_abs[0].is_moving = false;
+ }
touchpad-last_finger_state = touchpad-finger_state;
@@ -466,37 +521,36 @@ touchpad_update_state(struct touchpad_dispatch *touchpad,
uint32_t time)
return;
}
- touchpad-last_finger_state = touchpad-finger_state;
- if (!touchpad-hw_abs.x_valid || !touchpad-hw_abs.y_valid)
+ if (relevant_touch == -1)
return;
- if (!touchpad-hw_abs.is_moving)
+ if (!touchpad-hw_abs[relevant_touch].is_moving)
return;
/* Avoid noice by moving center only when delta reaches a threshold
* distance from the old center
[PATCH 7/8] evdev-touchpad: Use multitouch for Sony touchpads
From: Alexander E. Patrakov patra...@gmail.com
Track finger poritions and virtual buttons
---
src/evdev-touchpad.c | 168 +--
1 file changed, 149 insertions(+), 19 deletions(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index 01c52aa..53de1e7 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -76,9 +76,10 @@ struct touchpad_motion {
};
enum touchpad_fingers_state {
- TOUCHPAD_FINGERS_ONE = (1 0),
- TOUCHPAD_FINGERS_TWO = (1 1),
- TOUCHPAD_FINGERS_THREE = (1 2)
+ TOUCHPAD_FINGERS_NONE_YET = 1,
+ TOUCHPAD_FINGERS_ONE = (1 1),
+ TOUCHPAD_FINGERS_TWO = (1 2),
+ TOUCHPAD_FINGERS_THREE = (1 3)
};
enum fsm_event {
@@ -106,6 +107,7 @@ struct touchpad_dispatch {
int last_finger_state;
int slot;
int relevant_touch;
+ int virtual_buttons;
double constant_accel_factor;
double min_accel_factor;
@@ -127,6 +129,7 @@ struct touchpad_dispatch {
bool is_moving;
bool is_pressed;
+ bool tracking_id_changed;
} hw_abs[MAX_SLOTS + 1];
bool has_moved;
@@ -145,6 +148,11 @@ struct touchpad_dispatch {
int32_t center_y;
} hysteresis;
+ struct {
+ int32_t center_x;
+ int32_t separator_y;
+ } boundaries;
+
struct touchpad_motion motion_history[TOUCHPAD_HISTORY_LENGTH];
int motion_index;
unsigned int motion_count;
@@ -441,7 +449,7 @@ fsm_timout_handler(void *data)
}
static bool
-is_valid_touch(struct touchpad_dispatch *touchpad, int slot)
+is_valid_touch(struct touchpad_dispatch *touchpad, int slot, bool for_buttons)
{
if (!touchpad-hw_abs[slot].x_valid)
return false;
@@ -449,6 +457,14 @@ is_valid_touch(struct touchpad_dispatch *touchpad, int
slot)
return false;
if (!touchpad-hw_abs[slot].is_pressed)
return false;
+ if (touchpad-interaction_model == INTERACTION_MODEL_SONY) {
+ if (for_buttons
+ touchpad-hw_abs[slot].y touchpad-boundaries.separator_y)
+ return false;
+ if (!for_buttons
+ touchpad-hw_abs[slot].y =
touchpad-boundaries.separator_y)
+ return false;
+ }
return true;
}
@@ -466,12 +482,24 @@ touchpad_update_state(struct touchpad_dispatch *touchpad,
uint32_t time)
int last_valid_touch = -1;
int relevant_touch = touchpad-relevant_touch;
bool reset_motion = false;
+ int mt_finger_state = TOUCHPAD_FINGERS_NONE_YET;
- for (i = 0; i MAX_SLOTS; i++)
- if (is_valid_touch(touchpad, i)) {
+ for (i = 0; i MAX_SLOTS; i++) {
+ if (touchpad-hw_abs[i].tracking_id_changed)
+ touchpad-hw_abs[i].tracking_id_changed = false;
+ else if (is_valid_touch(touchpad, i, false)) {
touch_state |= 1 i;
last_valid_touch = i;
+ if (mt_finger_state TOUCHPAD_FINGERS_THREE)
+ mt_finger_state = mt_finger_state 1;
}
+ }
+
+ if (touchpad-interaction_model == INTERACTION_MODEL_SONY) {
+ touchpad-finger_state = 0;
+ if (mt_finger_state != TOUCHPAD_FINGERS_NONE_YET)
+ touchpad-finger_state = mt_finger_state;
+ }
if (touch_state !touchpad-touch_state) {
push_fsm_event(touchpad, FSM_EVENT_TOUCH);
@@ -634,13 +662,81 @@ process_absolute(struct touchpad_dispatch *touchpad,
}
static inline void
+process_absolute_sony(struct touchpad_dispatch *touchpad,
+ struct evdev_device *device,
+ struct input_event *e)
+{
+ int slot = touchpad-slot;
+ switch (e-code) {
+ case ABS_MT_SLOT:
+ slot = e-value;
+ if (slot 0 || slot = MAX_SLOTS)
+ slot = MAX_SLOTS;
+ touchpad-slot = slot;
+ break;
+ case ABS_MT_TRACKING_ID:
+ touchpad-hw_abs[slot].tracking_id_changed = true;
+ touchpad-hw_abs[slot].x_valid = false;
+ touchpad-hw_abs[slot].y_valid = false;
+ touchpad-hw_abs[slot].is_pressed = false;
+ touchpad-hw_abs[slot].is_moving = false;
+ break;
+ case ABS_MT_PRESSURE:
+ if (e-value touchpad-pressure.touch_high
+ !touchpad-hw_abs[slot].is_pressed)
+ on_touch(touchpad, slot);
+ else if (e-value touchpad-pressure.touch_low
+touchpad-hw_abs[slot].is_pressed)
+ on_release(touchpad, slot);
+ break;
+ case ABS_MT_POSITION_X:
+ if (touchpad-hw_abs[slot
[PATCH 8/8] evdev-touchpad: Autodetect known Sony-style touchpads
From: Alexander E. Patrakov patra...@gmail.com --- src/evdev-touchpad.c | 24 1 file changed, 24 insertions(+) diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c index 53de1e7..e36c2aa 100644 --- a/src/evdev-touchpad.c +++ b/src/evdev-touchpad.c @@ -193,7 +193,31 @@ configure_interaction_model(struct touchpad_dispatch *touchpad) case TOUCHPAD_MODEL_APPLETOUCH: touchpad-interaction_model = INTERACTION_MODEL_APPLE; break; + case TOUCHPAD_MODEL_SYNAPTICS: + case TOUCHPAD_MODEL_ELANTECH: + case TOUCHPAD_MODEL_ALPS: + /* +* FIXME: fallback to INTERACTION_MODEL_SIMPLE if out +* requirements such as multitouch support or pressure +* readings are not met. +*/ + touchpad-interaction_model = INTERACTION_MODEL_SONY; + break; default: + /* Note: Chromebook Pixel also gets here because of the following: +* I: Bus=0018 Vendor= Product= Version= +* N: Name=Atmel maXTouch Touchpad +* P: Phys=i2c-1-004b/input0 +* S: Sysfs=/devices/pci:00/:00:02.0/i2c-1/1-004b/input/input9 +* U: Uniq= +* H: Handlers=mouse1 event9 +* B: PROP=5 +* B: EV=b +* B: KEY=e520 1 0 0 0 0 +* B: ABS=6618103 +* +* Actually, Apple-style interaction is appropriate for Chromebooks. +*/ weston_log(Found a buttonpad of unknown type, assuming Apple-style\n); touchpad-interaction_model = INTERACTION_MODEL_APPLE; break; -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
