Re: SynPS/2 Synaptics TouchPad firmware bug
On 29/03/2014 04:54 , Alexander E. Patrakov wrote: 2014-03-29 0:16 GMT+06:00 Alexander E. Patrakov : 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? yes, tapping and software button areas are independent of each other and are enabled at the same time. clickfinger and software buttons are mutually exclusive (and the former is only enabled on apple touchpads anyway). Other than that anytime a click isn't what you expect it to be is likely a bug. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 6/8] test/Makefile.am: Use $(GCC_CFLAGS) from configure.ac
On Wed, Mar 26, 2014 at 04:21:47AM +0100, sardemff7+wayl...@sardemff7.net wrote: > On 25/03/2014 21:45, Jonas Ådahl wrote: > >Signed-off-by: Jonas Ådahl > >--- > > test/Makefile.am | 15 --- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > > >diff --git a/test/Makefile.am b/test/Makefile.am > >index b59d4a9..12ed023 100644 > >--- a/test/Makefile.am > >+++ b/test/Makefile.am > >@@ -2,6 +2,7 @@ if BUILD_TESTS > > AM_CPPFLAGS = -I$(top_srcdir)/src $(CHECK_CFLAGS) $(LIBEVDEV_CFLAGS) > > > > TEST_LIBS = liblitest.la $(CHECK_LIBS) $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS) > > $(top_builddir)/src/libinput.la -lm > >+TEST_CFLAGS = $(GCC_CFLAGS) $(AM_CPPFLAGS) > > AM_CPPFLAGS is wrong here, it must be AM_CFLAGS. The way it is > currently written (or with this patch) AM_CPPFLAGS are passed twice > while AM_CFLAGS are ignored. It may not be important but it is still > wrong. > You could also drop TEST_CFLAGS altogether and append the GCC_CFLAGS > to AM_CFLAGS in configure.ac. > > (In your C++ test patch, you should also add AM_CXXFLAGS to > test_build_cxx_CXXFLAGS.) > Thanks for the review, Quentin. I addressed the issues locally and pushed them as http://cgit.freedesktop.org/wayland/libinput/commit/?id=79827d24227c7ccbc8c238fb12f8eac12182ca1c and http://cgit.freedesktop.org/wayland/libinput/commit/?id=07750ef7988a98c1b3216fb6d52937c9ca07b539 Jonas > > -- > > Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] test: add litest helper functions for creating uinput devices
On Fri, Mar 28, 2014 at 03:22:44PM +1000, Peter Hutterer wrote:
> On Thu, Mar 27, 2014 at 05:10:34PM +0100, Jonas Ådahl wrote:
> > On Thu, Mar 27, 2014 at 08:48:02AM +1000, Peter Hutterer wrote:
> > > Both functions accept a series of event types/codes tuples, terminated by
> > > -1.
> > > For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is
> > > used
> > > as a property to enable.
> > >
> > > The _abs function als takes an array of absinfo, with absinfo.value
> > > determining the axis to change. If none are given, abs axes are
> > > initialized
> > > with default settings.
> > >
> > > Both functions abort on failure, so the caller does not need to check the
> > > return value.
> > >
> > > Example code for creating a rel device:
> > >
> > > struct libevdev_uinput *uinput;
> > > struct input_id id = { ... };
> > > uinput = litest_create_uinput_device("foo", &id,
> > > EV_REL, REL_X,
> > > EV_REL, REL_Y,
> > > EV_KEY, BTN_LEFT,
> > >INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
> > > -1);
> > > libevdev_uinput_write_event(uinput, EV_REL, REL_X, -1);
> > > libevdev_uinput_write_event(uinput, EV_SYN, SYN_REPORT, 0);
> > > ..
> > > libevdev_uinput_destroy(uinput);
> >
> > The problem with this approach is that its no longer possible to use the
> > litest_touch_down, litest_touch_up etc any more. Especially for touch
> > events thats an annoyance to reimplement in the test case. We could add
> > helpers for that but then we'd have double set of helpers for every kind
> > of event we want to test.
>
> how many devices are we talking about here. You're specifically creating a
> test device here that has one functionality that matters: a lot of slots.
> how many more devices do we expect similar to this?
>
> IMO at least for this case it's worth writing the extra couple of lines to
> have a custom device. Once we get past the number of devices we can look
> again to see if we have some sort of common denominator.
>
> also, litest_touch_down/up are already problematic. e.g. they don't release
> BTN_TOUCH or BTN_TOOL_FINGER because nothing refcounts the touches. they
> only solve the minimal test cases so far but the test suite needs a bit more
> work to be useful on a more general basis.
>
> > The way I'd want to use something like this is to create a fake device,
> > possibly with some special parameters, and then use it in the same way
> > I'd use a "normal" test device. I'd rather have a way to somehow create
> > a special fake device that can be operated in the same way using the
> > same functions as a "normal" fake device.
>
> the problem I see is with the special parameters. by the time you allow for
> all of them you end up re-implementing the current uinput API. e.g. your
> last device needed lots of slots, but what if the next device needs
> special pressure? which is exactly what I expect to be the next problem for
> the touchpad tests.
>
> I just start at the device description files and with the patch applied they
> are now little more than static descriptions of device capabilities with the
> odd for loop to write arrays out. Maybe a solution to this is to make it
> static but better exposed that you can literally take a device, adjust a few
> nobs in the cabability bits and then create it. Would that help?
Maybe what we can do is to just have a helper that creates a
litest_device given a generic type (mouse, keyboard, touch) and a array
of parameters that libevdev_enable_event_code() takes. The helper can have
a set of basic configuration per generic type than is overwritten by the
passed parameters and then passed to libevdev_enable_event_code().
This way we could easily create a special device with many touch points,
16 generic touch devices, or a touch device with very high resoultion.
In pseudo-C, it'd be something in the line of
struct litest_device *dev;
struct input_absinfo slot_abs = {
ABS_MT_SLOT, 0, 40, 0
};
struct litest_device_spec spec[] = {
{ EV_KEY, BTN_LEFT, NULL },
{ EV_KEY, BTN_RIGHT, NULL },
{ EV_ABS, ABS_MT_SLOT, &slot_abs },
};
dev = litest_create_generic_device(LITEST_TOUCH, &spec, 3);
litest_touch_down(dev, ...);
Jonas
>
> Cheers,
>Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: ANNOUNCE: New Wayland live CD
On Friday, March 28, 2014 12:30:17 PM Carlos Gomez, HCL America wrote: > nerdopolis - > > Thanks for the correction on the QT5 installation. I was able to run my > test. I love what you did because I can do "compile tests" on the live > distro and compare RBOS behavior to my Wayland development target. I am > using the vanilla Weston desktop you provided because that is what is > installed on our Wayland development target. > > What hardware (CPU and GPU) are you using? I want to know because I see a > lot of display issues (double cursor, repeating login prompts, cursor leaving > behind trails as if the background is not being restored) on the live distro > but I think that is my problem because of my choice of hardware (Dell laptops > of various vintage) and my lack of Wayland "configuration sophistication". I > didn't build the Wayland/OS install I am testing, I am just using it. I want > to give helpful feedback to the developer that is responsible for the Wayland > installation, and your distro is helping me to do that. > > Carlos > > From: wayland-devel [wayland-devel-boun...@lists.freedesktop.org] On Behalf > Of nerdopolis [bluescreen_aven...@verizon.net] > Sent: Sunday, March 23, 2014 5:05 PM > To: wayland-devel@lists.freedesktop.org > Subject: Re: ANNOUNCE: New Wayland live CD > > On Sunday, March 23, 2014 04:49:50 PM Carlos Gomez, HCL America wrote: > > nerdopolis - > > > > Thank you for doing all this hard work. I see that Qt 4.8.4 is installed. > > I need Qt 5.x. Is there another Wayland live CD with Qt 5.x that you know > > of? > > > > Thank You, > > > > Carlos > > > > From: wayland-devel [wayland-devel-boun...@lists.freedesktop.org] On Behalf > > Of nerdopolis [bluescreen_aven...@verizon.net] > > Sent: Friday, March 21, 2014 6:48 PM > > To: wayland-devel@lists.freedesktop.org > > Subject: Re: ANNOUNCE: New Wayland live CD > > > > On Friday, March 21, 2014 08:35:40 PM nerdopolis wrote: > > > Hi. > > > > > > > > > I am announcing new ISOs for my Wayland Live CD, which is named after my > > > favorite celebrity. > > > > > > > > > You can find the new ISOs here: > > > https://sourceforge.net/projects/rebeccablackos/files/2014-03-21/ > > > > > > Once again, the larger ISO is only larger because it has more development > > > headers, binaries with all the symbols, and more software installed to > > > compile and download source. The smaller ISO has no other reductions in > > > the user experience. > > > > > > Also please note that all of my checkinstall built packages have the > > > -rbos suffix, and mostly reside in /opt. So Wayland master is provided by > > > the wayland-rbos package, NOT the libwayland package that comes from the > > > system repos for example. > > > > > > Except there are small changes that I made for backporting a few things > > > for the release > > > DIFF of the changes to the SVN: http://pastebin.com/sDfA2izd > > > > > > They currently contain: > > > * Wayland Master > > > * Weston Master > > > * Wayland enabled Clutter > > > * Wayland enabled SDL > > > * Wayland enabled GTK > > > * Wayland enabled QT > > > * Wayland enabled EFL/Elementary > > > * Wayland enabled mplayer > > > * Wayland enabled gstreamer > > > * Orbital for Wayland (selectable at login) > > > https://github.com/giucam/orbital > > > * Hawaii for Wayland (selectable at login) https://github.com/mauios > > > * KDE Frameworks Wayland programs > > > * Native Calligra Wayland programs > > > * Wayland enabled Gnome-shell (selectable at login) *Does not work on > > > Virtualbox, except it can run nested > > > * A graphical utility for configuring udev for weston multiseat/multi > > > pointer > > > * A rudimentary but functional Wayland login manager written in Bash, > > > that supports user switching and session selection. > > > * Wayland enabled Enlightenment E19 *Does not work on Virtualbox > > > *hardcoded screen size > > > * SWC tiling Wayland server (use super+enter for terminal, and super+r > > > for dmenu) *Does not work on Virtualbox, and does not run nested. Only > > > tested on Intel (selectable at login) https://github.com/michaelforney/swc > > > * Menu options to run Gnome Shell Wayland, Enlightenment e19 Wayland, > > > Orbital, SWC, and Hawaii desktops as nested sessions. > > > > > > - > > > More security on KMS supported cards, and will be more secure on FB, > > > once bug https://bugs.freedesktop.org/show_bug.cgi?id=73782 is fixed and > > > I remove the setfacls from waylandloginmanager, by relying on udev's > > > UACCESS attribute, instead of global ACLs > > > > > > Waylandloginmanager's loginmanagerdisplay weston instance, as well as > > > all Zenity dialogs for the waylandloginmanager run as the daemom user, > > > instead of root. > > > > > > Waylandloginmanager has been improved to support entering a custom
Re: SynPS/2 Synaptics TouchPad firmware bug
2014-03-29 0:16 GMT+06:00 Alexander E. Patrakov : > 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: ANNOUNCE: New Wayland live CD
nerdopolis - Thanks for the correction on the QT5 installation. I was able to run my test. I love what you did because I can do "compile tests" on the live distro and compare RBOS behavior to my Wayland development target. I am using the vanilla Weston desktop you provided because that is what is installed on our Wayland development target. What hardware (CPU and GPU) are you using? I want to know because I see a lot of display issues (double cursor, repeating login prompts, cursor leaving behind trails as if the background is not being restored) on the live distro but I think that is my problem because of my choice of hardware (Dell laptops of various vintage) and my lack of Wayland "configuration sophistication". I didn't build the Wayland/OS install I am testing, I am just using it. I want to give helpful feedback to the developer that is responsible for the Wayland installation, and your distro is helping me to do that. Carlos From: wayland-devel [wayland-devel-boun...@lists.freedesktop.org] On Behalf Of nerdopolis [bluescreen_aven...@verizon.net] Sent: Sunday, March 23, 2014 5:05 PM To: wayland-devel@lists.freedesktop.org Subject: Re: ANNOUNCE: New Wayland live CD On Sunday, March 23, 2014 04:49:50 PM Carlos Gomez, HCL America wrote: > nerdopolis - > > Thank you for doing all this hard work. I see that Qt 4.8.4 is installed. > I need Qt 5.x. Is there another Wayland live CD with Qt 5.x that you know of? > > Thank You, > > Carlos > > From: wayland-devel [wayland-devel-boun...@lists.freedesktop.org] On Behalf > Of nerdopolis [bluescreen_aven...@verizon.net] > Sent: Friday, March 21, 2014 6:48 PM > To: wayland-devel@lists.freedesktop.org > Subject: Re: ANNOUNCE: New Wayland live CD > > On Friday, March 21, 2014 08:35:40 PM nerdopolis wrote: > > Hi. > > > > > > I am announcing new ISOs for my Wayland Live CD, which is named after my > > favorite celebrity. > > > > > > You can find the new ISOs here: > > https://sourceforge.net/projects/rebeccablackos/files/2014-03-21/ > > > > Once again, the larger ISO is only larger because it has more development > > headers, binaries with all the symbols, and more software installed to > > compile and download source. The smaller ISO has no other reductions in the > > user experience. > > > > Also please note that all of my checkinstall built packages have the -rbos > > suffix, and mostly reside in /opt. So Wayland master is provided by the > > wayland-rbos package, NOT the libwayland package that comes from the system > > repos for example. > > > > Except there are small changes that I made for backporting a few things for > > the release > > DIFF of the changes to the SVN: http://pastebin.com/sDfA2izd > > > > They currently contain: > > * Wayland Master > > * Weston Master > > * Wayland enabled Clutter > > * Wayland enabled SDL > > * Wayland enabled GTK > > * Wayland enabled QT > > * Wayland enabled EFL/Elementary > > * Wayland enabled mplayer > > * Wayland enabled gstreamer > > * Orbital for Wayland (selectable at login) > > https://github.com/giucam/orbital > > * Hawaii for Wayland (selectable at login) https://github.com/mauios > > * KDE Frameworks Wayland programs > > * Native Calligra Wayland programs > > * Wayland enabled Gnome-shell (selectable at login) *Does not work on > > Virtualbox, except it can run nested > > * A graphical utility for configuring udev for weston multiseat/multi > > pointer > > * A rudimentary but functional Wayland login manager written in Bash, > > that supports user switching and session selection. > > * Wayland enabled Enlightenment E19 *Does not work on Virtualbox > > *hardcoded screen size > > * SWC tiling Wayland server (use super+enter for terminal, and super+r > > for dmenu) *Does not work on Virtualbox, and does not run nested. Only > > tested on Intel (selectable at login) https://github.com/michaelforney/swc > > * Menu options to run Gnome Shell Wayland, Enlightenment e19 Wayland, > > Orbital, SWC, and Hawaii desktops as nested sessions. > > > > - > > More security on KMS supported cards, and will be more secure on FB, once > > bug https://bugs.freedesktop.org/show_bug.cgi?id=73782 is fixed and I > > remove the setfacls from waylandloginmanager, by relying on udev's UACCESS > > attribute, instead of global ACLs > > > > Waylandloginmanager's loginmanagerdisplay weston instance, as well as all > > Zenity dialogs for the waylandloginmanager run as the daemom user, instead > > of root. > > > > Waylandloginmanager has been improved to support entering a custom user > > name, if it doesn't appear from the user list, the user list shows the real > > names, the control fifo is write only for a standard user, so that they > > can't read the FIFO before the loginmanger, and a seperate FIFO for > > registering session information is root only, s
Re: SynPS/2 Synaptics TouchPad firmware bug
2014-03-29 0:16 GMT+06:00 Alexander E. Patrakov :
> 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"
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
---
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-28 10:48 GMT+06:00 Peter Hutterer :
> having said that, I'm currently struggling with getting libinput up to
> feature parity with the xorg drivers, hacking around broken devices will
> have to wait a bit, sorry.
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.
--
Alexander E. Patrakov
From e277805a6814c852e6a0a274b0bec7db93585e65 Mon Sep 17 00:00:00 2001
From: "Alexander E. Patrakov"
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
---
src/evdev-mt-touchpad.c | 48
src/evdev-mt-touchpad.h | 3 +++
2 files changed, 51 insertions(+)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index bbbd8f3..feddced 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)
{
@@ -407,6 +450,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);
}
@@ -430,6 +474,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;
@@ -776,6 +822,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 (libevdev_has_event_code(device->evdev, EV_KEY, BTN_MIDDLE) ||
libevdev_has_event_code(device->evdev, EV_KEY, BTN_RIGHT))
tp->buttons.has_buttons = true;
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 2bdb329..dc02014 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
};
@@ -110,6 +111,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: [PATCH V2 1/8] wesston: Add weston randr protocol
On Mon, 24 Mar 2014 19:39:13 +0800 Quanxian Wang wrote: > Weston protocol wrandr will provide interface to > 1) Mode set of output (scale, transform, mode) > 2) Position of output (currently support leftof, rightof) > 3) New a custom mode > 4) Delete mode > > This protocol is not expose public. It is only for > QA testing and Admin configuration currently. > > Signed-off-by: Quanxian Wang > --- > protocol/Makefile.am | 1 + > protocol/randr.xml | 228 > +++ > 2 files changed, 229 insertions(+) > create mode 100644 protocol/randr.xml > > diff --git a/protocol/Makefile.am b/protocol/Makefile.am > index 5e331a7..df2e070 100644 > --- a/protocol/Makefile.am > +++ b/protocol/Makefile.am > @@ -5,6 +5,7 @@ protocol_sources =\ > text.xml\ > input-method.xml\ > workspaces.xml \ > + randr.xml \ > text-cursor-position.xml\ > wayland-test.xml\ > xdg-shell.xml \ > diff --git a/protocol/randr.xml b/protocol/randr.xml > new file mode 100644 > index 000..07f83a4 > --- /dev/null > +++ b/protocol/randr.xml > @@ -0,0 +1,228 @@ > + > + > + > + > +Copyright © 2014 Quanxian Wang > +Copyright © 2014 Intel Corporation > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + The global interface exposing randr capabilities. > + As a weston_randr, that provides the interfaces for apps to more > operations > + on output. > + > + The aim of weston_randr is to get modes list, choose preferred mode, > + layout the output including position, rotate, and en/disable. > + The idea is from xrandr protocoal of xserver. It is very convenient for > + weston/wayland user to operates on mode setting of output. > + > + > + > + > + Informs the server that the client will not be using this > + protocol object anymore. This does not affect any other > + objects, weston_randr objects included. > + > + > + > + > + > + It is request notification when the next output randr commit > + is coming and is useful for notifying client the result of > + operations on the output. The randr request will take effect > + on the next weston_randr.commit. The notification will only be > + posted for one randr request unless requested again. > + > + > + Ok, the reply object is created as the first thing. What happens if you create multiple of them without sending commit in between? They all return the same result? Why do you have an output argument here? Are you explicitly forbidding the very useful case, where one could gather changes to multiple outputs into the same batch to be committed? I think that would be a misfeature. I don't see any reason to not allow changing multiple outputs in the same batch. Quite the contrary, when atomic modesetting becomes available in the kernel, we will be able to use it only if we allow changing multiple outputs at the same time in the protocol. It does not matter if the kernel or platform do not support atomic mode setting over multiple outputs, the protocol can and should still have it. > + > + > + > + > + These flags describe properties of an output mode. > + They are used in the flags bitfield of the mode event. > + Here we take the last 28-32th bit as additional flags > + which is different with original output mode. Sorry, how does this work? What mode event? If you mean wl_output.mode event, I'm not sure you can extend the flags there from here. wl_output would need to speci
Re: [PATCH 0/3] Add wl_output name event
On Wed, 19 Mar 2014 12:01:42 -0500 Jason Ekstrand wrote: > Quaxian, > I looked over the latest versions, and I think they all look good now from > a technical perspective. I'm still not 100% sure that this is needed, but > I think I'm ok with it. > --Jason Ekstrand Hi, yeah, seems good to me, too. I might like to change the wording slightly so that the name event is guaranteed to be sent, and not only "may be sent". I assume it is also supposed to belong to the set of state that is ended with the 'done' event, I guess that could be more clear, too. I imagine this would be useful also, if a client wants to show a menu with options to maximize or fullscreen onto a specific output. Listing the outputs by name would let the user know which is which. I guess presentation applications might like that to put something on the projector. Thanks, pq > On Wed, Mar 19, 2014 at 12:30 AM, Quanxian Wang > wrote: > > > This event contains a human-readable name of output. > > It may be sent after binding the output object. > > It is intended that the client can use this output name > > as a parameter or display it in logs. > > > > For example, in weston randr application, output name can > > be a parameter in command line to stand for an output. > > > > Quanxian Wang (3): > > wayland: Add wl_output name event > > shell: Add wl_output name event > > weston:Add wl_output name event > > > > Wayland: > > protocol/wayland.xml | 12 +++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > Shell: > > clients/desktop-shell.c | 12 ++-- > > clients/window.c| 12 ++-- > > 2 files changed, 20 insertions(+), 4 deletions(-) > > > > Weston: > > src/compositor.c| 7 +-- > > 1 files changed, 5 insertions(+), 2 deletions(-) > > > > -- > > 1.8.1.2 > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ANNOUNCE] libxkbcommon-0.4.1
Hi
On Thu, Mar 27, 2014 at 11:41 PM, Ran Benita wrote:
> Regarding intended use-case for multiple-keysyms, I consider it mainly
> to be for sequences with combining characters - not everything has
> precomposed codepoints, so if you want one of these, you don't have a
> way to do it with single-keysym, but it still conceptually fits in a
> keymap. However for the original intent you have to ask Daniel.
Ok, so should be handled as atomic key-press.
> Sure, the old functions are still useful for getting the "raw"
> translation if you want it. And you're right about the docs - I'll add
> some hopefully-not-too-confusing details instead of just "prefer the new
> ones". Full details are in the bugs and commit msgs but of course I
> don't expect anyone to read that :)
Yeah, commit-message is great for xkbcommon developers, not so much
for new API users. Thanks!
>> Btw., same is true for the implicit caps-lock magic in
>> xkb_state_key_get_one_sym(). I'm now quite confused whether
>> xkb_state_key_get_syms() users have to do caps-lock handling
>> explicitly? Or is that done by keymaps?
>
> Currently to get the implicit capitalization with get_syms(), you have
> to do this:
>
> int nsyms;
> const xkb_keysym_t *syms;
> xkb_keysym_t sym;
>
> nsyms = xkb_state_key_get_syms(..., &syms);
> if (nsyms == 1) {
> sym = xkb_state_key_get_one_sym(...);
> syms = &sym;
> }
>
> I imagine the disgust, but given the set of constraints we had I
> couldn't think of any way to make this work. New API is still possible,
> but then we'd have *three* ways to get keysyms...
>
> As I may have mentioned, I wanted to change the *keymaps* so the
> difference doesn't matter here. I still plan to send some patches for
> easy cases, but fixing other cases would require major xkeyboard-config
> surgery. So we're stuck with it.
That somehow gives me the impression capslock is currently not handled
by keymaps? Oh, didn't even notice that. Sounds like a gross hack. But
yes, fixing all keymaps sounds like rather cumbersome work given that
there's no real gain in it.
Thanks
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
