Re: [PATCH libinput v3 02/17] touchpad: after a click, lock the finger to its current position
On Tue, May 20, 2014 at 04:34:50PM +0200, Hans de Goede wrote:
From: Peter Hutterer peter.hutte...@who-t.net
On clickpads, clicking the pad usually causes some motion events. To avoid
erroneous movements, lock the finger into position on the click and don't
allow for motion events until we move past a given threshold (currently 2% of
the touchpad diagonal).
HdG:
Instead of pinning the lowest touch assuming that that is the one holding
the physical button, simply pin all touches, and unpin as soon as a touch
is moved more then the threshold.
Can you merge the two commit messages together into one? if we don't have
the original patch in the tree we don't need the specific history of this
patch. if you are concerned about preserving authorship feel free to change
to yourself as author or add a Co-authored-by: tag, either you or me, I
don't mind either way. That applies to all other patches too please.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Jonas Ådahl jad...@gmail.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad.c | 80
-
src/evdev-mt-touchpad.h | 12 +++-
2 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index b4a89e3..381bb90 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_BUTTON_MOTION_THRESHOLD 0.02 /* in percent of size */
Didn't spot this but the comment should probably be changed to
/* 2% of size */
to avoid confusion about it being 2% or 0.02%.
other than that - series looks good, rev-by where missing if you want.
tested on my x220 and on the T440s and it works as expected.
Send me a pull request for the lot and I'll merge it, no need to re-send all
these patches.
Cheers,
Peter
static inline int
tp_hysteresis(int in, int center, int margin)
@@ -158,6 +159,7 @@ tp_begin_touch(struct tp_dispatch *tp, struct tp_touch *t)
tp_motion_history_reset(t);
t-dirty = true;
t-state = TOUCH_BEGIN;
+ t-pinned.is_pinned = false;
tp-nfingers_down++;
assert(tp-nfingers_down = 1);
tp-queued |= TOUCHPAD_EVENT_MOTION;
@@ -182,6 +184,7 @@ tp_end_touch(struct tp_dispatch *tp, struct tp_touch *t)
t-dirty = true;
t-is_pointer = false;
t-state = TOUCH_END;
+ t-pinned.is_pinned = false;
assert(tp-nfingers_down = 1);
tp-nfingers_down--;
tp-queued |= TOUCHPAD_EVENT_MOTION;
@@ -346,50 +349,43 @@ tp_process_key(struct tp_dispatch *tp,
}
static void
-tp_unpin_finger(struct tp_dispatch *tp)
+tp_unpin_finger(struct tp_dispatch *tp, struct tp_touch *t)
{
- struct tp_touch *t;
- tp_for_each_touch(tp, t) {
- if (t-is_pinned) {
- t-is_pinned = false;
+ unsigned int xdist, ydist;
+ struct tp_touch *tmp = NULL;
+
+ if (!t-pinned.is_pinned)
+ return;
+
+ xdist = abs(t-x - t-pinned.center_x);
+ ydist = abs(t-y - t-pinned.center_y);
- if (t-state != TOUCH_END
- tp-nfingers_down == 1)
- t-is_pointer = true;
+ if (xdist * xdist + ydist * ydist
+ tp-buttons.motion_dist * tp-buttons.motion_dist)
+ return;
+
+ t-pinned.is_pinned = false;
+
+ tp_for_each_touch(tp, tmp) {
+ if (tmp-is_pointer)
break;
- }
}
+
+ if (t-state != TOUCH_END !tmp-is_pointer)
+ t-is_pointer = true;
}
static void
-tp_pin_finger(struct tp_dispatch *tp)
+tp_pin_fingers(struct tp_dispatch *tp)
{
- struct tp_touch *t,
- *pinned = NULL;
+ struct tp_touch *t;
tp_for_each_touch(tp, t) {
- if (t-is_pinned) {
- pinned = t;
- break;
- }
- }
-
- assert(!pinned);
-
- pinned = tp_current_touch(tp);
-
- if (tp-nfingers_down != 1) {
- tp_for_each_touch(tp, t) {
- if (t == pinned)
- continue;
-
- if (t-y pinned-y)
- pinned = t;
- }
+ t-is_pointer = false;
+ t-pinned.is_pinned = true;
+ t-pinned.center_x = t-x;
+ t-pinned.center_y = t-y;
}
-
- pinned-is_pinned = true;
- pinned-is_pointer = false;
}
static void
@@ -409,16 +405,19 @@ tp_process_state(struct tp_dispatch *tp, uint32_t time)
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Thu, 22 May 2014 08:24:04 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: And that becomes a pretty generic guide on How to build software, so if there is a site which already explains all these basics, we can link to it, but I don't think we should write that guide on the Wayland site. If the user is not familiar in general on building software manually from source, then he should be looking for pre-packaged Wayland and Weston for his particular distribution. There is one reason to have a more thorough guide though: end users reporting bugs, who are then asked to test a patch or the latest git version. But every project out there has this problem, surely someone has written a relatively generic guide? An attempt: http://who-t.blogspot.com.au/2014/05/configure-fails-with-no-package-foo.html happy to fix it up where needed. That is an excellent write-up! Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Thu, 22 May 2014 00:18:23 +0200 Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 21, 2014 at 12:30:18PM +0300, Pekka Paalanen wrote: On Tue, 20 May 2014 13:12:32 -0700 Bill Spitzak spit...@gmail.com wrote: [...] I have to tell you that such one-line-at-a-time cut paste is unbelievably tedious, and my biggest screwups when trying this on a second machine was when I missed the slight variations in the autogen lines because I was using uparrow to re-run the commands from the last repository. That convinced me to remove the $ signs, although I agree with you that it is not as nice looking. They are not meant to be copied repeatedly. Even basic common sense says, that if you end up copying them more than once, it would probably be worth to save them in a script. If you manually do those commands every single time you open a new terminal to work in, you are bound to miss something. The commands are an example. They are the foundation on which you can write your own environment setup. OTOH, git-clone is ran only once. 'make' and 'make install' come from the spine. autogen.sh/configure arguments are better saved in a script if there are many of them like for Mesa, but you can always see them in 'head config.log', too. Would it be an option to provide a jhbuild script that can be used to automatically build everything from source? That should at least remove any ambiguities or distribution specifics and should always work. Doing so has two advantages: it is a script and therefore can save everybody from a lot of typing (or copy/pasting) and it documents the origin and exact command sequences required to build from source. If not everything is to be built from source there is apparently also a way to specify dependencies (via pkg-config files!) that are assumed to be installed by the distribution. I think back in the early days many people used jhbuild to build modular X, though its usage seems to have declined. But perhaps that's just because its so common that nobody considers it worth mentioning anymore or X has stabilized to a point where building everything from source is no longer required. To be honest, I'm not familiar with jhbuild. I have seen people mention it on #wayland, though, and fighting with it. It could be nice - should it perhaps be checked into git somewhere, so one can keep track of the changes? Where? As I personally am on a rolling-release distribution, I don't tend to see much problems with too old distro packages. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/2] touchpad: Make pointer movements a bit faster by default
On Tue, May 20, 2014 at 11:19:50PM +0200, Jonas Ådahl wrote: Alter the so far hard coded parameters a bit to make the pointer acceleration profile accelerate the pointer movement a bit more than before. This is much better on both the x220 and the t440s. The only problem I see is that on the x220, which has a touchpad in ca 16:9 format the vertical motion is now noticably faster than the horizontal motion. we need to compensate for that soon. https://bugs.freedesktop.org/show_bug.cgi?id=79056, so we don't forget. Meanwhile, please apply this one. Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Cheers, Peter Signed-off-by: Jonas Ådahl jad...@gmail.com --- src/evdev-mt-touchpad.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c index 109441d..6c63cb6 100644 --- a/src/evdev-mt-touchpad.c +++ b/src/evdev-mt-touchpad.c @@ -28,9 +28,9 @@ #include evdev-mt-touchpad.h -#define DEFAULT_CONSTANT_ACCEL_NUMERATOR 50 -#define DEFAULT_MIN_ACCEL_FACTOR 0.16 -#define DEFAULT_MAX_ACCEL_FACTOR 1.0 +#define DEFAULT_CONSTANT_ACCEL_NUMERATOR 100 +#define DEFAULT_MIN_ACCEL_FACTOR 0.20 +#define DEFAULT_MAX_ACCEL_FACTOR 0.40 #define DEFAULT_HYSTERESIS_MARGIN_DENOMINATOR 700.0 static inline int -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 0.2
A new release of libinput, 0.2, is available. The most significant change since 0.1 is the introduction of the new multi touch touchpad driver by Peter Hutterer, replacing the old one from weston. While there are improvements already in the queue, please test and file bugs you find. Other than that, apart for bug fixes and documentation fixes there are some API additions as well: One can now get the seat wide button count at the time of an event using libinput_event_keyboard_get_seat_key_count(..) libinput_event_pointer_get_seat_button_count(..) One can now in a type safe manner get the base event given a type specific event, for example libinput_event_keyboard_get_base_event(..) Also libinput_device_get_keys() returns -errno on error instead of -1. The stability of the API is the same as the previous release, meaning that it is yet to be promised. You can download the source code by checking out the 0.2.0 tag from git://anongit.freedesktop.org/wayland/libinput or just download the tarball from: http://www.freedesktop.org/software/libinput/libinput-0.2.0.tar.xz MD5: 76472cd9764ac40615442cb911c621a1 SHA1: 12df214465bf52d3022c0671918c35d208b7bc38 SHA256: 822bad40cac1fa90e38569da189a989d4b5f8ef58ec6bc6fefef8b78f825599c Enjoy! Jonas signature.asc Description: Digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Wed, 21 May 2014 12:17:29 -0700 Bill Spitzak spit...@gmail.com wrote: On 05/21/2014 02:30 AM, Pekka Paalanen wrote: Yeah, nowadays Weston can work with a released version of xkbcommon, so we could remove the git-clone part, and have a link to its home page. Collecting links to depended-on projects' home pages would be nice in the generic guide. To be consistent it seems like any package where the necessary version has been released should not be listed with build instructions, as it may be possible on somebody's machine to compile without it. It is a bit fuzzy. It also depends a bit on whether distributions have had time to pick it up. I think the minimal on a fully-up-to-date system is this: wayland (on the assumption that you may want to hack it) mesa (because it depends on wayland) libinput weston xserver (because it depends on wayland) Is this correct? Should mesa and xserver even be removed? They probably work even if compiled with an older wayland, right? It looks about right to me. Mesa should stay, because quite probably many distributions do not yet enable Wayland support in it, and we might still get development there. Xserver needs to stay, because 1.16 has not been released yet, it receives active development benefiting Wayland (glamor), and I assume most distributions are not building the Xwayland server anyway. From the original build directions this removes drm, libkbdcommon, cairo and pixman, and I think a few others. Mesa seems to bump its libdrm requirement quite often, but OTOH libdrm is easy to build, nothing special there. xkbcommon we could drop especially if it doesn't really need --with-xkb-config-root option anymore. So pointing to the web pages of libdrm and xkbcommon should suffice, I think. It looks like xkbcommon 0.3.0 already uses pkg-config to find the xkb-config-root path from the xkeyboard-config package, falls back to $prefix/share/X11/xkb by default. Looks like the guide really does not need --with-xkb-config-root option. However, the guide should probably mention xkeyboard-config package. It is required for xkbcommon (and therefore normals keyboards) to work. xkeyboard-config has been providing its .pc file since May 2010. Most people already have xkeyboard-config installed because they have Xorg, but for an X11-less system it could be missing. Cairo was included in the guide probably because distributions had varying configurations wrt. enabling GL or GLESv2 support, and because the GL/GLESv2 code was new and in development. If we drop the need for cairo-gl/glesv2, we can drop Cairo and Pixman from the guide. I'm not sure why Pixman was there, maybe as a Cairo dependency. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Thu, May 22, 2014 at 09:25:40AM +0300, Pekka Paalanen wrote: On Thu, 22 May 2014 00:18:23 +0200 Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 21, 2014 at 12:30:18PM +0300, Pekka Paalanen wrote: On Tue, 20 May 2014 13:12:32 -0700 Bill Spitzak spit...@gmail.com wrote: [...] I have to tell you that such one-line-at-a-time cut paste is unbelievably tedious, and my biggest screwups when trying this on a second machine was when I missed the slight variations in the autogen lines because I was using uparrow to re-run the commands from the last repository. That convinced me to remove the $ signs, although I agree with you that it is not as nice looking. They are not meant to be copied repeatedly. Even basic common sense says, that if you end up copying them more than once, it would probably be worth to save them in a script. If you manually do those commands every single time you open a new terminal to work in, you are bound to miss something. The commands are an example. They are the foundation on which you can write your own environment setup. OTOH, git-clone is ran only once. 'make' and 'make install' come from the spine. autogen.sh/configure arguments are better saved in a script if there are many of them like for Mesa, but you can always see them in 'head config.log', too. Would it be an option to provide a jhbuild script that can be used to automatically build everything from source? That should at least remove any ambiguities or distribution specifics and should always work. Doing so has two advantages: it is a script and therefore can save everybody from a lot of typing (or copy/pasting) and it documents the origin and exact command sequences required to build from source. If not everything is to be built from source there is apparently also a way to specify dependencies (via pkg-config files!) that are assumed to be installed by the distribution. I think back in the early days many people used jhbuild to build modular X, though its usage seems to have declined. But perhaps that's just because its so common that nobody considers it worth mentioning anymore or X has stabilized to a point where building everything from source is no longer required. To be honest, I'm not familiar with jhbuild. I have seen people mention it on #wayland, though, and fighting with it. It could be nice - should it perhaps be checked into git somewhere, so one can keep track of the changes? Yes, I think it should definitely be checked in somewhere so people can easily keep their copy up-to-date. Where? Good question. Neither the wayland nor the weston repository look like they'd be a good fit. Perhaps it could be a separate repository? Or perhaps make it part of wayland-web? That sounds like a bad choice at first, but it would put the jhbuild scripts close to the building guide and therefore may have advantages. As I personally am on a rolling-release distribution, I don't tend to see much problems with too old distro packages. So am I, and I usually build distributions from scratch anyway so I already have a set of scripts to build everything anyway. But there are evidently people who are in a different situation and it may be helpful to have some automatic build that they can run if they encounter bugs and need to test patches. Thierry pgpB1pyw3eZNN.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Thu, May 22, 2014 at 09:14:30AM +0200, Thierry Reding wrote: On Thu, May 22, 2014 at 09:25:40AM +0300, Pekka Paalanen wrote: On Thu, 22 May 2014 00:18:23 +0200 Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 21, 2014 at 12:30:18PM +0300, Pekka Paalanen wrote: On Tue, 20 May 2014 13:12:32 -0700 Bill Spitzak spit...@gmail.com wrote: [...] I have to tell you that such one-line-at-a-time cut paste is unbelievably tedious, and my biggest screwups when trying this on a second machine was when I missed the slight variations in the autogen lines because I was using uparrow to re-run the commands from the last repository. That convinced me to remove the $ signs, although I agree with you that it is not as nice looking. They are not meant to be copied repeatedly. Even basic common sense says, that if you end up copying them more than once, it would probably be worth to save them in a script. If you manually do those commands every single time you open a new terminal to work in, you are bound to miss something. The commands are an example. They are the foundation on which you can write your own environment setup. OTOH, git-clone is ran only once. 'make' and 'make install' come from the spine. autogen.sh/configure arguments are better saved in a script if there are many of them like for Mesa, but you can always see them in 'head config.log', too. Would it be an option to provide a jhbuild script that can be used to automatically build everything from source? That should at least remove any ambiguities or distribution specifics and should always work. Doing so has two advantages: it is a script and therefore can save everybody from a lot of typing (or copy/pasting) and it documents the origin and exact command sequences required to build from source. If not everything is to be built from source there is apparently also a way to specify dependencies (via pkg-config files!) that are assumed to be installed by the distribution. I think back in the early days many people used jhbuild to build modular X, though its usage seems to have declined. But perhaps that's just because its so common that nobody considers it worth mentioning anymore or X has stabilized to a point where building everything from source is no longer required. we haven't had huge changes that required everyone to rebuild everything regularly - most people get by only updating their specific module set. I think that contributes most to the decline of jhbuild. To be honest, I'm not familiar with jhbuild. I have seen people mention it on #wayland, though, and fighting with it. It could be nice - should it perhaps be checked into git somewhere, so one can keep track of the changes? Yes, I think it should definitely be checked in somewhere so people can easily keep their copy up-to-date. Where? Good question. Neither the wayland nor the weston repository look like they'd be a good fit. Perhaps it could be a separate repository? Or perhaps make it part of wayland-web? That sounds like a bad choice at first, but it would put the jhbuild scripts close to the building guide and therefore may have advantages. the jhbuild script is an xml module file and a jhbuildrc, since you're hosting them somewhere anyway the web project should be good enough. for examples see http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules and http://cgit.freedesktop.org/xorg/util/modular/tree/jhbuildrc An example with version information is here: http://cgit.freedesktop.org/xorg/util/modular/tree/xorg-7.6.modules so you can decide that some combination is useful for a 1.5 release and keep those together. fwiw, jhbuild is convenient. I use it regularly to build gnome or parts of it and especially for multi-repository projects that I only work on rarely and/or irregularly it is very helpful. the build instructions are then: clone jhbuild, make install it, run jhbuild build, wait and hope. Cheers, Peter As I personally am on a rolling-release distribution, I don't tend to see much problems with too old distro packages. So am I, and I usually build distributions from scratch anyway so I already have a set of scripts to build everything anyway. But there are evidently people who are in a different situation and it may be helpful to have some automatic build that they can run if they encounter bugs and need to test patches. Thierry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v3 02/17] touchpad: after a click, lock the finger to its current position
Hi, On 05/22/2014 08:05 AM, Peter Hutterer wrote: On Tue, May 20, 2014 at 04:34:50PM +0200, Hans de Goede wrote: From: Peter Hutterer peter.hutte...@who-t.net On clickpads, clicking the pad usually causes some motion events. To avoid erroneous movements, lock the finger into position on the click and don't allow for motion events until we move past a given threshold (currently 2% of the touchpad diagonal). HdG: Instead of pinning the lowest touch assuming that that is the one holding the physical button, simply pin all touches, and unpin as soon as a touch is moved more then the threshold. Can you merge the two commit messages together into one? if we don't have the original patch in the tree we don't need the specific history of this patch. if you are concerned about preserving authorship feel free to change to yourself as author or add a Co-authored-by: tag, either you or me, I don't mind either way. That applies to all other patches too please. Done. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Jonas Ådahl jad...@gmail.com Reviewed-by: Hans de Goede hdego...@redhat.com Reviewed-by: Peter Hutterer peter.hutte...@who-t.net --- src/evdev-mt-touchpad.c | 80 - src/evdev-mt-touchpad.h | 12 +++- 2 files changed, 50 insertions(+), 42 deletions(-) diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c index b4a89e3..381bb90 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_BUTTON_MOTION_THRESHOLD 0.02 /* in percent of size */ Didn't spot this but the comment should probably be changed to /* 2% of size */ to avoid confusion about it being 2% or 0.02%. Fixed. other than that - series looks good, rev-by where missing if you want. tested on my x220 and on the T440s and it works as expected. Send me a pull request for the lot and I'll merge it, no need to re-send all these patches. I'm going through your review comments now, I'll send a pull-req when I'm done. Regards, Hans ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v3 09/17] touchpad: Rework is_pointer handling
On 05/22/2014 05:35 AM, Peter Hutterer wrote:
On Tue, May 20, 2014 at 04:34:57PM +0200, Hans de Goede wrote:
We don't want touches in the button area to cause the pointer to move. So
instead of making a touch the pointer when it moves to TOUCH_BEGIN, wait
with making it the pointer until its buttons state moves to
BUTTON_STATE_AREA.
Note that a touch in the main area of the touchpad will move to
BUTTON_STATE_AREA immediately.
I stared at that code for a while before I realised why this wouldn't
regress older touchpads - please add here that If software-buttons are not
enabled, any finger is in the BUTTON_STATE_AREA.
Updated the commit msg with this.
two more style-only fixes below.
While at it also refactor the is_pointer setting in general, removing
code duplicition wrt checking that another touch is not already
the pointer on unpinning a finger, and add safeguards that unpinning
does not make a finger which is not in button state BUTTON_STATE_AREA the
pointer, nor that the button code makes a pinned finger the pointer.
All these sanity checks are combined into a new tp_button_active function,
since they should be taken into account for 2 finger scrolling, etc. too.
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 7 ++
src/evdev-mt-touchpad.c | 49
+
src/evdev-mt-touchpad.h | 6 +
test/touchpad.c | 8 +++
4 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c
b/src/evdev-mt-touchpad-buttons.c
index 61055ac..e47a55e 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -142,6 +142,7 @@ tp_button_set_state(struct tp_dispatch *tp, struct
tp_touch *t,
break;
case BUTTON_STATE_AREA:
t-button.curr = BUTTON_EVENT_IN_AREA;
+tp_set_pointer(tp, t);
break;
case BUTTON_STATE_BOTTOM:
break;
@@ -598,3 +599,9 @@ tp_post_button_events(struct tp_dispatch *tp, uint32_t
time)
return rc;
}
+
+int
+tp_button_touch_active(struct tp_dispatch *tp, struct tp_touch *t)
+{
+return t-button.state == BUTTON_STATE_AREA;
+}
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7f73f6e..924ba16 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -152,8 +152,6 @@ tp_get_touch(struct tp_dispatch *tp, unsigned int slot)
static inline void
tp_begin_touch(struct tp_dispatch *tp, struct tp_touch *t)
{
-struct tp_touch *tmp = NULL;
-
if (t-state != TOUCH_UPDATE) {
tp_motion_history_reset(t);
t-dirty = true;
@@ -162,15 +160,6 @@ tp_begin_touch(struct tp_dispatch *tp, struct tp_touch
*t)
tp-nfingers_down++;
assert(tp-nfingers_down = 1);
tp-queued |= TOUCHPAD_EVENT_MOTION;
-
-tp_for_each_touch(tp, tmp) {
-if (tmp-is_pointer)
-break;
-}
-
-if (!tmp-is_pointer) {
-t-is_pointer = true;
-}
}
}
@@ -342,7 +331,6 @@ static void
tp_unpin_finger(struct tp_dispatch *tp, struct tp_touch *t)
{
unsigned int xdist, ydist;
-struct tp_touch *tmp = NULL;
if (!t-pinned.is_pinned)
return;
@@ -350,19 +338,11 @@ tp_unpin_finger(struct tp_dispatch *tp, struct
tp_touch *t)
xdist = abs(t-x - t-pinned.center_x);
ydist = abs(t-y - t-pinned.center_y);
-if (xdist * xdist + ydist * ydist
-tp-buttons.motion_dist * tp-buttons.motion_dist)
-return;
-
-t-pinned.is_pinned = false;
-
-tp_for_each_touch(tp, tmp) {
-if (tmp-is_pointer)
-break;
+if (xdist * xdist + ydist * ydist =
+tp-buttons.motion_dist * tp-buttons.motion_dist) {
don't indent the line here please.
No idea what exactly you want me to do here, note the indentation is unchanged
from the original check a few lines higher up. Not fixed.
+t-pinned.is_pinned = false;
+tp_set_pointer(tp, t);
}
-
-if (t-state != TOUCH_END !tmp-is_pointer)
-t-is_pointer = true;
}
static void
@@ -378,6 +358,27 @@ tp_pin_fingers(struct tp_dispatch *tp)
}
}
+static int
+tp_touch_active(struct tp_dispatch *tp, struct tp_touch *t)
+{
+return (t-state == TOUCH_BEGIN || t-state == TOUCH_UPDATE)
+!t-pinned.is_pinned tp_button_touch_active(tp, t);
+}
+
+void tp_set_pointer(struct tp_dispatch *tp, struct tp_touch *t)
please add a line-break after void
Done.
Regards,
Hans
Cheers,
Peter
+{
+struct tp_touch *tmp = NULL;
+
+/* Only set the touch as pointer if we don't have one yet */
+
Re: [PATCH libinput v3 11/17] touchpad: Ignore non left clicks on clickpads
Hi,
On 05/22/2014 03:45 AM, Peter Hutterer wrote:
On Tue, May 20, 2014 at 04:34:59PM +0200, Hans de Goede wrote:
We should never get any non left button events on clickpads, but if we
do these might confuse our state, so complain about it and ignore these.
Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/evdev-mt-touchpad-buttons.c
b/src/evdev-mt-touchpad-buttons.c
index 76e6843..f1d65be 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -367,6 +367,13 @@ tp_process_button(struct tp_dispatch *tp,
uint32_t time)
{
uint32_t mask = 1 (e-code - BTN_LEFT);
+
+/* Ignore other buttons on clickpads */
+if (tp-buttons.is_clickpad e-code != BTN_LEFT) {
+log_bug(received non BTN_LEFT button event on a clickpad
(kernel bug?)\n);
I'd be useful to print the actual button code here.
log_bug(received %s button event on a clickpad (kernel bug?)\n,
libevdev_event_code_get_name(tp-device-evdev, EV_KEY, e-code));
Done.
Regards,
Hans
Cheers,
Peter
+return 0;
+}
+
if (e-value) {
tp-buttons.state |= mask;
tp-queued |= TOUCHPAD_EVENT_BUTTON_PRESS;
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PULL] libinput clickpad improvements
Hi Peter, Please pull from my personal libinput git repo for the libinput clickpad improvements we've been working on: The following changes since commit 40bae41159d9694c4089aedc58e2abd261f8106f: configure.ac: libinput 0.2 (2014-05-22 08:10:42 +0200) are available in the git repository at: git://people.freedesktop.org/~jwrdegoede/libinput clickpad-improvements-v2 for you to fetch changes up to 89165da6d6b90d466edf3283b710c0931bdcc8dd: Change internal timestamps to uint64_t to properly deal with wrapping (2014-05-22 14:51:41 +0200) Hans de Goede (9): touchpad: Rework is_pointer handling touchpad: Use INPUT_PROP_BUTTONPAD instead of checking for buttons touchpad: Ignore non left clicks on clickpads touchpad: post_button_events: Remove TOUCHPAD_EVENT_BUTTON_PRESS/RELEASE test touchpad: softbuttons: Deal with a click arriving before any touches touchpad: Ignore fingers in button area for 2 finger scroll touchpad: Remove clickpad clicked test from 2 finger scrolling handling touchpad: handle_timeouts: Remove unused return value Change internal timestamps to uint64_t to properly deal with wrapping Peter Hutterer (7): touchpad: set ntouches for single-touch pads depending on key bits touchpad: after a click, lock the finger to its current position touchpad: reset the tap timer_fd to -1 on destroy touchpad: move button-related code into a separate file doc: add state machine SVG to EXTRA_DIST touchpad: save the active clickfinger button touchpad: Add clickpad-style software buttons doc/Makefile.am | 4 +- doc/touchpad-softbutton-state-machine.svg | 390 +++ src/Makefile.am | 1 + src/evdev-mt-touchpad-buttons.c | 625 ++ src/evdev-mt-touchpad-tap.c | 46 +-- src/evdev-mt-touchpad.c | 271 ++--- src/evdev-mt-touchpad.h | 87 - src/evdev-touchpad.c | 26 +- src/evdev.c | 12 +- src/evdev.h | 2 +- src/filter.c | 16 +- src/filter.h | 6 +- src/libinput.h| 40 ++ test/litest-bcm5974.c | 1 + test/touchpad.c | 20 +- 15 files changed, 1317 insertions(+), 230 deletions(-) create mode 100644 doc/touchpad-softbutton-state-machine.svg create mode 100644 src/evdev-mt-touchpad-buttons.c Regards, Hans p.s. The Change internal timestamps to uint64_t to properly deal with wrapping patch causes Jonas' acceleration patches to no longer apply, I've a rebased version of them available in my master branch. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
- One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Does this device turn on more than 1 bit for multitouch on the strips? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On 05/21/2014 03:24 PM, Peter Hutterer wrote: On Tue, May 20, 2014 at 07:58:59AM -0400, Jasper St. Pierre wrote: Fedora has this built-in: # yum install 'pkgconfig(laalaa.pc)' And that becomes a pretty generic guide on How to build software, so if there is a site which already explains all these basics, we can link to it, but I don't think we should write that guide on the Wayland site. If the user is not familiar in general on building software manually from source, then he should be looking for pre-packaged Wayland and Weston for his particular distribution. There is one reason to have a more thorough guide though: end users reporting bugs, who are then asked to test a patch or the latest git version. But every project out there has this problem, surely someone has written a relatively generic guide? An attempt: http://who-t.blogspot.com.au/2014/05/configure-fails-with-no-package-foo.html happy to fix it up where needed. Cheers, Peter Looks really good to me! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
It's # yum install 'pkgconfig(foo)'; not # yum install 'pkg-config(foo)' The inconsistent hyphenation is annoying. On Thu, May 22, 2014 at 6:15 AM, Peter Hutterer peter.hutte...@who-t.netwrote: On Thu, May 22, 2014 at 09:14:30AM +0200, Thierry Reding wrote: On Thu, May 22, 2014 at 09:25:40AM +0300, Pekka Paalanen wrote: On Thu, 22 May 2014 00:18:23 +0200 Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 21, 2014 at 12:30:18PM +0300, Pekka Paalanen wrote: On Tue, 20 May 2014 13:12:32 -0700 Bill Spitzak spit...@gmail.com wrote: [...] I have to tell you that such one-line-at-a-time cut paste is unbelievably tedious, and my biggest screwups when trying this on a second machine was when I missed the slight variations in the autogen lines because I was using uparrow to re-run the commands from the last repository. That convinced me to remove the $ signs, although I agree with you that it is not as nice looking. They are not meant to be copied repeatedly. Even basic common sense says, that if you end up copying them more than once, it would probably be worth to save them in a script. If you manually do those commands every single time you open a new terminal to work in, you are bound to miss something. The commands are an example. They are the foundation on which you can write your own environment setup. OTOH, git-clone is ran only once. 'make' and 'make install' come from the spine. autogen.sh/configure arguments are better saved in a script if there are many of them like for Mesa, but you can always see them in 'head config.log', too. Would it be an option to provide a jhbuild script that can be used to automatically build everything from source? That should at least remove any ambiguities or distribution specifics and should always work. Doing so has two advantages: it is a script and therefore can save everybody from a lot of typing (or copy/pasting) and it documents the origin and exact command sequences required to build from source. If not everything is to be built from source there is apparently also a way to specify dependencies (via pkg-config files!) that are assumed to be installed by the distribution. I think back in the early days many people used jhbuild to build modular X, though its usage seems to have declined. But perhaps that's just because its so common that nobody considers it worth mentioning anymore or X has stabilized to a point where building everything from source is no longer required. we haven't had huge changes that required everyone to rebuild everything regularly - most people get by only updating their specific module set. I think that contributes most to the decline of jhbuild. To be honest, I'm not familiar with jhbuild. I have seen people mention it on #wayland, though, and fighting with it. It could be nice - should it perhaps be checked into git somewhere, so one can keep track of the changes? Yes, I think it should definitely be checked in somewhere so people can easily keep their copy up-to-date. Where? Good question. Neither the wayland nor the weston repository look like they'd be a good fit. Perhaps it could be a separate repository? Or perhaps make it part of wayland-web? That sounds like a bad choice at first, but it would put the jhbuild scripts close to the building guide and therefore may have advantages. the jhbuild script is an xml module file and a jhbuildrc, since you're hosting them somewhere anyway the web project should be good enough. for examples see http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules and http://cgit.freedesktop.org/xorg/util/modular/tree/jhbuildrc An example with version information is here: http://cgit.freedesktop.org/xorg/util/modular/tree/xorg-7.6.modules so you can decide that some combination is useful for a 1.5 release and keep those together. fwiw, jhbuild is convenient. I use it regularly to build gnome or parts of it and especially for multi-repository projects that I only work on rarely and/or irregularly it is very helpful. the build instructions are then: clone jhbuild, make install it, run jhbuild build, wait and hope. Cheers, Peter As I personally am on a rolling-release distribution, I don't tend to see much problems with too old distro packages. So am I, and I usually build distributions from scratch anyway so I already have a set of scripts to build everything anyway. But there are evidently people who are in a different situation and it may be helpful to have some automatic build that they can run if they encounter bugs and need to test patches. Thierry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On 05/22/2014 12:01 AM, Pekka Paalanen wrote: It looks about right to me. Mesa should stay, because quite probably many distributions do not yet enable Wayland support in it, and we might still get development there. Xserver needs to stay, because 1.16 has not been released yet, it receives active development benefiting Wayland (glamor), and I assume most distributions are not building the Xwayland server anyway. I was thinking Mesa and Xserver would have to stay even if new enough versions were released, because they actually call libwayland-*. Without this they will be running Mesa and Xserver compiled for (and linked with?) the distributed libwayland-* rather than the one they may be trying to modify. Cairo was included in the guide probably because distributions had varying configurations wrt. enabling GL or GLESv2 support, and because the GL/GLESv2 code was new and in development. If we drop the need for cairo-gl/glesv2, we can drop Cairo and Pixman from the guide. I'm not sure why Pixman was there, maybe as a Cairo dependency. I am going to try to do a bisect and find out what version of Cairo fixes the xserver bug. But it should not be in the main instructions. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
On Thu, May 22, 2014 at 8:45 AM, Bill Spitzak spit...@gmail.com wrote: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Does this device turn on more than 1 bit for multitouch on the strips? No. Neither the touchstrips nor touchrings are multitouch, and I don't see any practical reason for them to be made multitouch in the future (on our devices they're intended to act like scroll wheels). Certainly such hardware could be made[1] but I don't think representing it to clients as a bitvector would be optimal. [1]: http://hackaday.com/2012/06/09/theremin-takes-the-touch-out-of-multitouch/ Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
I started out using a script somebody wrote to build on Debian. But I had to edit it considerably as dependencies changed and eventually I reverted to pretty much cut paste of the configure lines. It also installed about 100 packages, many of which were not needed (either unused or because I had to compile from git anyway). This is why I never tried to submit build instructions until I was able to run this carefully on a clean machine, as all those installations hid what was needed. A script written in a more useful language than shell might help, as it could define functions for the very repetitive part. The only thing that changes with each dependency is the name of the git repository and the configure options. Plus a few annoying ones that don't use autogen.sh or that require extra commands to be typed. On 05/21/2014 03:18 PM, Thierry Reding wrote: Would it be an option to provide a jhbuild script that can be used to automatically build everything from source? That should at least remove any ambiguities or distribution specifics and should always work. Doing so has two advantages: it is a script and therefore can save everybody from a lot of typing (or copy/pasting) and it documents the origin and exact command sequences required to build from source. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On 05/21/2014 03:09 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 02:54:36PM -0700, Bill Spitzak wrote: On 05/21/2014 02:16 PM, Thierry Reding wrote: While I agree with the other points, I think it's perfectly consistent for --version to output the version of pkg-config itself. There's --modversion if you want to query the version of a given package. It's fine that pkg-config --version prints the version of pkg-config. My complaint is that pkg-config --version xyz does the exact same thing, completely ignoring the xyz! Even that is completely consistent. I've tried a number of binaries on my system and they all behave in exactly the same way. gcc, ar, gdb, ld, libtool and even chromium ignore anything that follows --version. That's exactly the bogus excuse I expect to get to dismiss my bug report, thanks. That is however bulls**t. The computer is our slave, not the other way around. Doing exactly what nobody in their right mind would expect is not being helpful, no matter how logical it is. All I want is an error that says you probably wanted to use --modversion. If other gnu software acts like you say (gcc does not) they should be fixed to complain about the unnecessary extra arguments. When I use a program that I've never used before I tend to go read the manpage or at least see if there's anything interesting in the --help output. If you run pkg-config --help or look at the manpage it clearly states that --version will output the version of pkg-config. It also says that --modversion will output the version for a package. Of course I used --help and the man page, or I would not have gotten as far as trying --version. The help and man page mention modversion exactly once. They then use the word version and VERSION about 1000 times. It also does not help that about 2/3 of the time they use the word package and only about 1/3 of the time they use the word module. Technically you are correct but there is not a chance in hell that anybody will read and remember it correctly. It is just like the Emacs help, which is like playing zork, in that technically you have everything you need but only if you read and memorized every help message you saw since you started the program. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
On Wed, May 21, 2014 at 10:17 PM, Chandler Paul thatsly...@gmail.com wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. I'll take a look over the patches and see if I can provide any comments. I haven't looked at the libinput code before, so I'll probably be stumbling around for a bit :D On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho wrote: Hey there!, Here's a few patches to have libinput handle events from tablets, these devices are basically pointer devices, with a varying range of extra buttons (either stylus or pad buttons), and extra ABS_* axes. These devices also often offer information about the stylus in use, and its BTN_TOOL_* codes. So I've gone for reusing and extending libinput_event_pointer, adding extra libinput_pointer_axis values, and adding an axis_frame event to mark the end of a set of simultaneous axis changes, and a tool_update event to mark tool changes (and delimit proximity). These features are only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. I'm with Peter on splitting these up. It seems kind of inconsistent with the rest of libinput (with what I've gathered, anyway). A tablet-specific event sounds interesting too, but I feel like compressing all of the axis changes into. For now I'm going to work on having all the axis changes reported as separate POINTER_AXIS events. Caveats: * Many of these devices have also tactile strips or wheels, but these are unhandled so far... On the devices I've got available for testing, current kernel support seems varyingly inconsistent: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Graphically, a bit moving across a field like that makes sense, but I think that would be a difficult value to make practical use of in an application without changing it to a simple 1-13 value. If I get far enough that I can start implementing support for tactile strips and all those other fancy features some of these tablets have I might have it convert the values for tactile strips like that to something more usable by default and leave the other axes as-is. I'm curious to hear Ping and Jason's opinion on this though, and what kind of advantages Having the pad functions work well is very useful, but definitely secondary to proper pen support. The way our driver (ab)uses the kernel's event interface to send wheel data is a minor tragedy, and is something I am very much hoping Benjamin and I will be able to address in the coming months (I've been side-tracked by other things for the past few weeks, but just turned my mind back to the problem). If working around what currently exists is too much of a time sink, I wouldn't worry too much: pad support is useful, but clearly secondary to getting the pen working properly. - Another device has one wheel, reported through ABS_WHEEL. Even though min/max are reported as [0..1023], on interaction it goes [0..71] (funky range too) We could just forward this as-is, but seems hindering enough to do anything useful with those unless that behavior is corrected. When supported, IMO it'd make sense to have those axes behave similar to scroll axes, so the axis value increments or decrements depending on the direction. I'm not sure if there would be cases where the absolute value matters here? * One thing worth noting is that axes are currently normalized, to [-1..1] for stylus tilt, and [0..1] for everything else. I remember Peter's tablet wayland protocol proposal basically forwarded input_absinfo, this might not be fully compatible with that, although TBH I'm unsure clamping/normalization should take place so high in the stack... I'm with Peter on this actually. If the axes were used for something else I might approve of normalization in libinput but I think having absolute values fits more of the use cases for the extra axes found on many tablets, especially since Ping said that some of Wacom's in-house applications actually need these. I do think however, that maybe we should consider clamping axis values with libinput even if we don't normalize the axes by default. IMO, normalization makes a lot of sense and libinput is a fine place to do it. Applications use axis data for various reasons. For instance an app may read pressure
Re: [PATCH libinput 0/24] Tablet support
On Thu, 2014-05-22 at 11:17 -0700, Jason Gerecke wrote: On Wed, May 21, 2014 at 10:17 PM, Chandler Paul thatsly...@gmail.com wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. I'll take a look over the patches and see if I can provide any comments. I haven't looked at the libinput code before, so I'll probably be stumbling around for a bit :D That's fine, I'm very thankful you're taking the time to help me out anyway :). Plus I'm still stumbling a bit on libinput myself, so I can relate! IMO, normalization makes a lot of sense and libinput is a fine place to do it. Applications use axis data for various reasons. For instance an app may read pressure values to adjust brush size, change the ink flow rate, or possibly even simulate the pressure-varying effects of a paint knife. When using data, the application can interpret it in two ways*: as unitless quantity or as a number with some attached unit. _Many_ applications don't particularly care about units and will simply ignore any unit information provided. They take the data, normalize it, and use that fractional value to scale some other quantity (brush size, flow rate, degree of paint drag). Even data that you normally associate with a unit is typically treated this way. For instance, tilt angles are liberally interpreted and as long as the values are centered and increase/decrease properly most applications could care less about the underlying units**. For these applications, normalizing the data up-front just makes things easier: the API is cleaner since you just move around a bunch of floats, and it saves applications from doing the normalization that they're going to do anyway. You're completely right on this. Even if we provided functions for normalizing the data, having our default behavior with returning axis values aimed at a niche market of applications probably isn't the best idea, and will leave implementations lot messier then we want them. The more functions a client needs to call, the messier and less appealing working with libinput will be. Now, that said, there is a small class of applications that make use of the units for one reason or another. Perhaps it is a drafting application that measures physical distances in cm between two points, or perhaps it is that drawing application from earlier now modeling the physical effects of a given number of newtons of force on the tool/ink/canvas. These kinds of uses are niche, but we should absolutely not prevent developers from being able to make them. What is important to the developer in this case is that the data is accompanied with enough information to put it into physical context; at the very least this means transmitting the physical resolution of the data. Now, you could provide the raw data to an application but there's not really any point. One application might want to work in centimeters, the next in inches, the next in meters. In short, though applications interested in units aren't going to /normalize/ the data, there's a good chance they're going to /rescale/ the data. And if they're rescaling the data to their unit-of-choice anyway, it doesn't really matter what unit the data is ingested in since the resolution information is available. Based on that, I think it makes a lot of sense to pre-process the data. Applications don't use the raw values as-is anyway, so if pre-processing allows for a simpler and easier-to-understand interface then it should be seriously considered. Some axes might make more sense canonicalized rather than normalized (e.g. angles might make more sense in radians rather than fractions of a [semi-]circle) but that's a separate issue. You bring up a very good point, the way you put it normalization definitely makes a lot of sense, and I probably will make sure it can be done through libinput. And you're right; libraries are meant to give developers the ability to do things in their applications more easily, and if we're limiting the values returned to being normalized or being raw we're going against that philosophy. I see uses for raw values, but with the points you brought up I also definitely see uses for normalized values too. So I think I'm going to re-implement normalization on my branch in a way that allows a client application to do both. he more functions a client has to call to get the values they need, the messier their code will be and the less appealing using libinput will seem. We also want a design that will (hopefully) last for a long time, without needing to be completely rewritten in the future. So I think the best way of doing this is to just have libinput provide calls for grabbing normalized values off any given axis event, and
[PATCH weston 5/5] desktop-shell: make background applications less dark
---
desktop-shell/shell.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 51683ee..a5886d7 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -911,21 +911,21 @@ animate_focus_change(struct desktop_shell *shell, struct
workspace *ws,
if (focus_surface_created) {
ws-focus_animation = weston_fade_run(
ws-fsurf_front-view,
- ws-fsurf_front-view-alpha, 0.6, 300,
+ ws-fsurf_front-view-alpha, 0.4, 300,
focus_animation_done, ws);
} else if (from) {
wl_list_insert(from-layer_link,
ws-fsurf_back-view-layer_link);
ws-focus_animation = weston_stable_fade_run(
ws-fsurf_front-view, 0.0,
- ws-fsurf_back-view, 0.6,
+ ws-fsurf_back-view, 0.4,
focus_animation_done, ws);
} else if (to) {
wl_list_insert(ws-layer.view_list,
ws-fsurf_back-view-layer_link);
ws-focus_animation = weston_stable_fade_run(
ws-fsurf_front-view, 0.0,
- ws-fsurf_back-view, 0.6,
+ ws-fsurf_back-view, 0.4,
focus_animation_done, ws);
}
}
--
2.0.0.rc2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 0/5] desktop-shell tweaks for maynard shell
These patches were written in the development of the Maynard desktop shell client for the Raspberry Pi: https://github.com/raspberrypi/maynard They're quite simple and deal with: 1. fixing weston_move_scale_run() after it was broken a while ago, 2. putting the panel somewhere other than the top in desktop-shell, 3. making sure animations always run regardless of repaints, 4. a small aesthetic tweak. desktop-shell/shell.c | 264 +++ desktop-shell/shell.h | 2 + protocol/desktop-shell.xml | 20 ++- src/animation.c| 15 +- src/spring-tool.c | 5 + 5 files changed, 242 insertions(+), 64 deletions(-) Cheerio, -- Jonny Lamb ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/5] animation: fix move scale animation
Both weston_move_scale_run() and weston_slide_run() were broken in commit 3a869019. Commit a4a6f161 fixed and explained the problem for weston_slide_run() but weston_move_scale_run() remained broken. To fix weston_move_scale_run(), weston_view_animation_run() is also required. It was removed when _run() was split into two functions _create() and _run() in commit f5cc2b56, but _run() was not added in this commit. --- src/animation.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/animation.c b/src/animation.c index a29b34a..392e32d 100644 --- a/src/animation.c +++ b/src/animation.c @@ -458,8 +458,10 @@ weston_move_scale_run(struct weston_view *view, int dx, int dy, if (animation == NULL) return NULL; - weston_spring_init(animation-spring, 400.0, start, end); + weston_spring_init(animation-spring, 400.0, 0.0, 1.0); animation-spring.friction = 1150; + weston_view_animation_run(animation); + return animation; } -- 2.0.0.rc2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/5] desktop-shell: use panel location to calculate correct sizes and ranges
Now the client can let us know where the panel is using
desktop_shell.set_panel_position, we can correctly calculate where to
put new views and how big maximized views should be.
---
desktop-shell/shell.c | 229 ++
1 file changed, 173 insertions(+), 56 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index e586922..51683ee 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -251,9 +251,10 @@ shell_fade_startup(struct desktop_shell *shell);
static struct shell_seat *
get_shell_seat(struct weston_seat *seat);
-static int
-get_output_panel_height(struct desktop_shell *shell,
- struct weston_output *output);
+static void
+get_output_panel_size(struct desktop_shell *shell,
+ struct weston_output *output,
+ int *width, int *height);
static void
shell_surface_update_child_surface_layers(struct shell_surface *shsurf);
@@ -351,24 +352,54 @@ shell_grab_start(struct shell_grab *grab,
}
}
-static int
-get_output_panel_height(struct desktop_shell *shell,
- struct weston_output *output)
+static void
+get_output_panel_size(struct desktop_shell *shell,
+ struct weston_output *output,
+ int *width,
+ int *height)
{
struct weston_view *view;
- int panel_height = 0;
- if (!output)
- return 0;
+ if (output) {
+ wl_list_for_each(view, shell-panel_layer.view_list,
layer_link) {
+ if (view-surface-output == output) {
+ float x, y;
- wl_list_for_each(view, shell-panel_layer.view_list, layer_link) {
- if (view-surface-output == output) {
- panel_height = view-surface-height;
- break;
+ if (shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_TOP ||
+ shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_BOTTOM) {
+
+ weston_view_to_global_float(view,
+
view-surface-width, 0,
+ x, y);
+
+ *width = (int) x;
+ *height = view-surface-height + (int)
y;
+
+ return;
+
+ } else if (shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_LEFT ||
+ shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_RIGHT) {
+
+ weston_view_to_global_float(view,
+ 0,
view-surface-height,
+ x, y);
+
+ *width = view-surface-width + (int) x;
+ *height = (int) y;
+
+ return;
+ }
+ }
}
}
- return panel_height;
+ /* output is NULL or the correct view wasn't found */
+ *width = 0;
+ *height = 0;
}
static void
@@ -389,13 +420,20 @@ send_configure_for_surface(struct shell_surface *shsurf)
height = shsurf-output-height;
} else if (state-maximized) {
struct desktop_shell *shell;
- uint32_t panel_height = 0;
+ int32_t panel_width = 0, panel_height = 0;
shell = shell_surface_get_shell(shsurf);
- panel_height = get_output_panel_height(shell, shsurf-output);
+ get_output_panel_size(shell, shsurf-output,
+ panel_width, panel_height);
width = shsurf-output-width;
height = shsurf-output-height - panel_height;
+
+ if (shell-panel_position == DESKTOP_SHELL_PANEL_POSITION_LEFT
||
+ shell-panel_position ==
DESKTOP_SHELL_PANEL_POSITION_RIGHT) {
+ width = shsurf-output-width - panel_width;
+ height = shsurf-output-height;
+ }
} else {
width = 0;
height = 0;
@@ -1545,23 +1583,57 @@ static void
constrain_position(struct weston_move_grab *move, int *cx, int *cy)
{
struct shell_surface *shsurf = move-base.shsurf;
+ struct desktop_shell *shell = shsurf-shell;
struct weston_pointer *pointer = move-base.grab.pointer;
- int x, y, panel_height, bottom;
+ int x, y, panel_width,
[PATCH weston 4/5] animation: ensure repaints are always scheduled during animations
Animations are run off the repaint cycle so if there's nothing to
repaint, an animation will stop running. This is usually not a problem
as each frame function of an animation causes something to change and
therefore a repaint to happen. This patch helps detect when the
animation isn't in said case and triggers a repaint to keep the
animation running.
This problem was found by using weston_move_scale_run() to move a view
onscreen from completely off. The very first time the animation frame
function was called the progress wasn't enough to move it into
view. The compositor saw there was nothing to repaint and stopped
doing anything else. When something else (like a pointer move) forced
a redraw, the view's position was very much onscreen and jumped into
view in an ugly way.
---
src/animation.c | 11 +++
src/spring-tool.c | 5 +
2 files changed, 16 insertions(+)
diff --git a/src/animation.c b/src/animation.c
index 392e32d..5ded3ad 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -161,6 +161,8 @@ weston_view_animation_frame(struct weston_animation *base,
struct weston_view_animation *animation =
container_of(base,
struct weston_view_animation, animation);
+ struct weston_compositor *compositor =
+ animation-view-surface-compositor;
if (base-frame_counter = 1)
animation-spring.timestamp = msecs;
@@ -178,6 +180,15 @@ weston_view_animation_frame(struct weston_animation *base,
weston_view_geometry_dirty(animation-view);
weston_view_schedule_repaint(animation-view);
+
+ /* The view's output_mask will be zero if its position is
+* offscreen. Animations should always run but as they are also
+* run off the repaint cycle, if there's nothing to repaint
+* the animation stops running. Therefore if we catch this situation
+* and schedule a repaint on all outputs it will be avoided.
+*/
+ if (animation-view-output_mask == 0)
+ weston_compositor_schedule_repaint(compositor);
}
static struct weston_view_animation *
diff --git a/src/spring-tool.c b/src/spring-tool.c
index 41cc52c..685bfd9 100644
--- a/src/spring-tool.c
+++ b/src/spring-tool.c
@@ -40,6 +40,11 @@ weston_view_schedule_repaint(struct weston_view *view)
{
}
+WL_EXPORT void
+weston_compositor_schedule_repaint(struct weston_compositor *compositor)
+{
+}
+
int
main(int argc, char *argv[])
{
--
2.0.0.rc2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/5] desktop-shell: add set_panel_position to help place views onscreen
Panels are always assumed to be on the top edge of the output. If this
is not the case views will be placed under the panel, wherever it is,
and maximize doesn't use the correct space allocated for views.
By telling the server on which edge the panel is located, it can
correctly calculate where to put new views and how big maximized views
should be.
---
desktop-shell/shell.c | 29 ++---
desktop-shell/shell.h | 2 ++
protocol/desktop-shell.xml | 20 +++-
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index dd0b2f9..e586922 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4093,13 +4093,34 @@ desktop_shell_desktop_ready(struct wl_client *client,
shell_fade_startup(shell);
}
+static void
+desktop_shell_set_panel_position(struct wl_client *client,
+struct wl_resource *resource,
+uint32_t position)
+{
+ struct desktop_shell *shell = wl_resource_get_user_data(resource);
+
+ if (position != DESKTOP_SHELL_PANEL_POSITION_TOP
+ position != DESKTOP_SHELL_PANEL_POSITION_BOTTOM
+ position != DESKTOP_SHELL_PANEL_POSITION_LEFT
+ position != DESKTOP_SHELL_PANEL_POSITION_RIGHT) {
+ wl_resource_post_error(resource,
+ WL_DISPLAY_ERROR_INVALID_OBJECT,
+ bad position argument);
+ return;
+ }
+
+ shell-panel_position = position;
+}
+
static const struct desktop_shell_interface desktop_shell_implementation = {
desktop_shell_set_background,
desktop_shell_set_panel,
desktop_shell_set_lock_surface,
desktop_shell_unlock,
desktop_shell_set_grab_surface,
- desktop_shell_desktop_ready
+ desktop_shell_desktop_ready,
+ desktop_shell_set_panel_position
};
static enum shell_surface_type
@@ -5305,7 +5326,7 @@ bind_desktop_shell(struct wl_client *client,
struct wl_resource *resource;
resource = wl_resource_create(client, desktop_shell_interface,
- MIN(version, 2), id);
+ MIN(version, 3), id);
if (client == shell-child.client) {
wl_resource_set_implementation(resource,
@@ -6226,7 +6247,7 @@ module_init(struct weston_compositor *ec,
return -1;
if (wl_global_create(ec-wl_display,
-desktop_shell_interface, 2,
+desktop_shell_interface, 3,
shell, bind_desktop_shell) == NULL)
return -1;
@@ -6240,6 +6261,8 @@ module_init(struct weston_compositor *ec,
shell-child.deathstamp = weston_compositor_get_time();
+ shell-panel_position = DESKTOP_SHELL_PANEL_POSITION_TOP;
+
setup_output_destroy_handler(ec, shell);
loop = wl_display_get_event_loop(ec-wl_display);
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index 6e63785..f50acac 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -204,6 +204,8 @@ struct desktop_shell {
struct wl_listener output_move_listener;
struct wl_list output_list;
+ uint32_t panel_position;
+
char *client;
};
diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index fdcb17b..57c204a 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -1,6 +1,6 @@
protocol name=desktop
- interface name=desktop_shell version=2
+ interface name=desktop_shell version=3
description summary=create desktop widgets and helpers
Traditional user interfaces can rely on this interface to define the
foundations of typical desktops. Currently it's possible to set up
@@ -94,6 +94,24 @@
/description
/request
+!-- Version 3 additions --
+
+enum name=panel_position
+ entry name=top value=0/
+ entry name=bottom value=1/
+ entry name=left value=2/
+ entry name=right value=3/
+/enum
+
+request name=set_panel_position since=3
+ arg name=position type=uint/
+ description summary=set panel position
+Tell the shell which side of the screen the panel is
+located. This is so that new windows do not overlap the panel
+and maximized windows maximize properly.
+ /description
+/request
+
/interface
interface name=screensaver version=1
--
2.0.0.rc2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Added depencies and bug fixes to build instructions
On Thu, May 22, 2014 at 09:35:23AM -0700, Bill Spitzak wrote: On 05/21/2014 03:09 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 02:54:36PM -0700, Bill Spitzak wrote: On 05/21/2014 02:16 PM, Thierry Reding wrote: While I agree with the other points, I think it's perfectly consistent for --version to output the version of pkg-config itself. There's --modversion if you want to query the version of a given package. It's fine that pkg-config --version prints the version of pkg-config. My complaint is that pkg-config --version xyz does the exact same thing, completely ignoring the xyz! Even that is completely consistent. I've tried a number of binaries on my system and they all behave in exactly the same way. gcc, ar, gdb, ld, libtool and even chromium ignore anything that follows --version. That's exactly the bogus excuse I expect to get to dismiss my bug report, thanks. That is however bulls**t. The computer is our slave, not the other way around. Doing exactly what nobody in their right mind would expect is not being helpful, no matter how logical it is. All I want is an error that says you probably wanted to use --modversion. then submit a patch and see. it took me less than 3 hours to submit patches for the two other bugs you submitted, and you've now probably spent more time arguing about how it will get rejected than you would've spent fixing it in the first place. please realise that nobody in their right mind would do $FOO is nothing but an insult, directed not just at those who disagree with you but also at those may agree with you but just hadn't seen it as a problem before. don't expect this to improve the conversation or lead to a conclusion in your favour. If other gnu software acts like you say (gcc does not) they should be fixed to complain about the unnecessary extra arguments. there is such a thing of promised functionality. changing how commandline arguments are handled can break existing scripts, causing havoc beyond the benefit the change brings in. When I use a program that I've never used before I tend to go read the manpage or at least see if there's anything interesting in the --help output. If you run pkg-config --help or look at the manpage it clearly states that --version will output the version of pkg-config. It also says that --modversion will output the version for a package. Of course I used --help and the man page, or I would not have gotten as far as trying --version. The help and man page mention modversion exactly once. They then use the word version and VERSION about 1000 times. It also does not help that about 2/3 of the time they use the word package and only about 1/3 of the time they use the word module. Technically you are correct but there is not a chance in hell that anybody will read and remember it correctly. It is just like the Emacs help, which is like playing zork, in that technically you have everything you need but only if you read and memorized every help message you saw since you started the program. and a helpful contribution would be to at least submit bugs or patches to improve the man page. wayland developers are not the pkg-config maintainers (afaik) so we're really just wasting time on this list discussing this back and forth. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PULL] libinput clickpad improvements
On Thu, May 22, 2014 at 03:22:47PM +0200, Hans de Goede wrote: Hi Peter, Please pull from my personal libinput git repo for the libinput clickpad improvements we've been working on: The following changes since commit 40bae41159d9694c4089aedc58e2abd261f8106f: configure.ac: libinput 0.2 (2014-05-22 08:10:42 +0200) are available in the git repository at: git://people.freedesktop.org/~jwrdegoede/libinput clickpad-improvements-v2 for you to fetch changes up to 89165da6d6b90d466edf3283b710c0931bdcc8dd: Change internal timestamps to uint64_t to properly deal with wrapping (2014-05-22 14:51:41 +0200) merged 4e669bf..5082eaf master - master thanks Cheers, Peter Hans de Goede (9): touchpad: Rework is_pointer handling touchpad: Use INPUT_PROP_BUTTONPAD instead of checking for buttons touchpad: Ignore non left clicks on clickpads touchpad: post_button_events: Remove TOUCHPAD_EVENT_BUTTON_PRESS/RELEASE test touchpad: softbuttons: Deal with a click arriving before any touches touchpad: Ignore fingers in button area for 2 finger scroll touchpad: Remove clickpad clicked test from 2 finger scrolling handling touchpad: handle_timeouts: Remove unused return value Change internal timestamps to uint64_t to properly deal with wrapping Peter Hutterer (7): touchpad: set ntouches for single-touch pads depending on key bits touchpad: after a click, lock the finger to its current position touchpad: reset the tap timer_fd to -1 on destroy touchpad: move button-related code into a separate file doc: add state machine SVG to EXTRA_DIST touchpad: save the active clickfinger button touchpad: Add clickpad-style software buttons doc/Makefile.am | 4 +- doc/touchpad-softbutton-state-machine.svg | 390 +++ src/Makefile.am | 1 + src/evdev-mt-touchpad-buttons.c | 625 ++ src/evdev-mt-touchpad-tap.c | 46 +-- src/evdev-mt-touchpad.c | 271 ++--- src/evdev-mt-touchpad.h | 87 - src/evdev-touchpad.c | 26 +- src/evdev.c | 12 +- src/evdev.h | 2 +- src/filter.c | 16 +- src/filter.h | 6 +- src/libinput.h| 40 ++ test/litest-bcm5974.c | 1 + test/touchpad.c | 20 +- 15 files changed, 1317 insertions(+), 230 deletions(-) create mode 100644 doc/touchpad-softbutton-state-machine.svg create mode 100644 src/evdev-mt-touchpad-buttons.c Regards, Hans p.s. The Change internal timestamps to uint64_t to properly deal with wrapping patch causes Jonas' acceleration patches to no longer apply, I've a rebased version of them available in my master branch. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
Hi, First of all, I'm sorry I dropped the ball this long. It's great to see you've been doing some progress. On jue, 2014-05-22 at 01:17 -0400, Chandler Paul wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho wrote: Hey there!, Here's a few patches to have libinput handle events from tablets, these devices are basically pointer devices, with a varying range of extra buttons (either stylus or pad buttons), and extra ABS_* axes. These devices also often offer information about the stylus in use, and its BTN_TOOL_* codes. So I've gone for reusing and extending libinput_event_pointer, adding extra libinput_pointer_axis values, and adding an axis_frame event to mark the end of a set of simultaneous axis changes, and a tool_update event to mark tool changes (and delimit proximity). These features are only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. I'm with Peter on splitting these up. It seems kind of inconsistent with the rest of libinput (with what I've gathered, anyway). A tablet-specific event sounds interesting too, but I feel like compressing all of the axis changes into. For now I'm going to work on having all the axis changes reported as separate POINTER_AXIS events. I'm not against making this a separate set of event types. I would advise though against attempting to compress axis changes into a single event, it puts certain processing burden on clients, and most of those not always want as much data. Independently of this being a separate set of events, IMO the axis frame event is still useful for pointer events, this might help compressing the processing of dx/dy for scrolling in clients for example, instead of processing 2 events that queue the redraw of different areas, some unneeded in the end. Caveats: * Many of these devices have also tactile strips or wheels, but these are unhandled so far... On the devices I've got available for testing, current kernel support seems varyingly inconsistent: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Graphically, a bit moving across a field like that makes sense, but I think that would be a difficult value to make practical use of in an application without changing it to a simple 1-13 value. If I get far enough that I can start implementing support for tactile strips and all those other fancy features some of these tablets have I might have it convert the values for tactile strips like that to something more usable by default and leave the other axes as-is. I'm curious to hear Ping and Jason's opinion on this though, and what kind of advantages - Another device has one wheel, reported through ABS_WHEEL. Even though min/max are reported as [0..1023], on interaction it goes [0..71] (funky range too) We could just forward this as-is, but seems hindering enough to do anything useful with those unless that behavior is corrected. When supported, IMO it'd make sense to have those axes behave similar to scroll axes, so the axis value increments or decrements depending on the direction. I'm not sure if there would be cases where the absolute value matters here? * One thing worth noting is that axes are currently normalized, to [-1..1] for stylus tilt, and [0..1] for everything else. I remember Peter's tablet wayland protocol proposal basically forwarded input_absinfo, this might not be fully compatible with that, although TBH I'm unsure clamping/normalization should take place so high in the stack... I'm with Peter on this actually. If the axes were used for something else I might approve of normalization in libinput but I think having absolute values fits more of the use cases for the extra axes found on many tablets, especially since Ping said that some of Wacom's in-house applications actually need these. I do think however, that maybe we should consider clamping axis values with libinput even if we don't normalize the axes by default. I've forked libinput and I have a branch where I'm fixing up the patches Carlos sent in based on the feedback from Peter. You can find it here: https://github.com/Lyude1337/libinput/tree/carlos_cleanup
Re: [PATCH libinput 0/24] Tablet support
Hey Jason, On jue, 2014-05-22 at 11:17 -0700, Jason Gerecke wrote: On Wed, May 21, 2014 at 10:17 PM, Chandler Paul thatsly...@gmail.com wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. I'll take a look over the patches and see if I can provide any comments. I haven't looked at the libinput code before, so I'll probably be stumbling around for a bit :D On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho wrote: Hey there!, Here's a few patches to have libinput handle events from tablets, these devices are basically pointer devices, with a varying range of extra buttons (either stylus or pad buttons), and extra ABS_* axes. These devices also often offer information about the stylus in use, and its BTN_TOOL_* codes. So I've gone for reusing and extending libinput_event_pointer, adding extra libinput_pointer_axis values, and adding an axis_frame event to mark the end of a set of simultaneous axis changes, and a tool_update event to mark tool changes (and delimit proximity). These features are only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. I'm with Peter on splitting these up. It seems kind of inconsistent with the rest of libinput (with what I've gathered, anyway). A tablet-specific event sounds interesting too, but I feel like compressing all of the axis changes into. For now I'm going to work on having all the axis changes reported as separate POINTER_AXIS events. Caveats: * Many of these devices have also tactile strips or wheels, but these are unhandled so far... On the devices I've got available for testing, current kernel support seems varyingly inconsistent: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Graphically, a bit moving across a field like that makes sense, but I think that would be a difficult value to make practical use of in an application without changing it to a simple 1-13 value. If I get far enough that I can start implementing support for tactile strips and all those other fancy features some of these tablets have I might have it convert the values for tactile strips like that to something more usable by default and leave the other axes as-is. I'm curious to hear Ping and Jason's opinion on this though, and what kind of advantages Having the pad functions work well is very useful, but definitely secondary to proper pen support. The way our driver (ab)uses the kernel's event interface to send wheel data is a minor tragedy, and is something I am very much hoping Benjamin and I will be able to address in the coming months (I've been side-tracked by other things for the past few weeks, but just turned my mind back to the problem). If working around what currently exists is too much of a time sink, I wouldn't worry too much: pad support is useful, but clearly secondary to getting the pen working properly. As far as the glitches are limited to a known bunch, I guess it might not be much of a problem to have those worked around, might be harder though if input_absinfo info is forwarded, unless we make it as-is or not depending on the value. But I agree this is a secondary goal, if a fix is approachable in drivers, we can just use the same approach than for every other axis and wait for the fix there. - Another device has one wheel, reported through ABS_WHEEL. Even though min/max are reported as [0..1023], on interaction it goes [0..71] (funky range too) We could just forward this as-is, but seems hindering enough to do anything useful with those unless that behavior is corrected. When supported, IMO it'd make sense to have those axes behave similar to scroll axes, so the axis value increments or decrements depending on the direction. I'm not sure if there would be cases where the absolute value matters here? * One thing worth noting is that axes are currently normalized, to [-1..1] for stylus tilt, and [0..1] for everything else. I remember Peter's tablet wayland protocol proposal basically forwarded input_absinfo, this might not be fully compatible with that, although TBH I'm unsure clamping/normalization should take place so high in the stack... I'm with Peter on this actually. If the axes were used for
Re: [PATCH libinput 0/24] Tablet support
Hi Ping! On lun, 2014-04-21 at 18:03 -0700, Ping Cheng wrote: Benjamin is right. Those are absolute values. Most Linux applications do not use those extra values. But, there are in-house applications need those values. I'll have to ask around to give you some use cases if you are interested. Very late reply, but... I would certainly find some usecases interesting. For strips, I see this making sense (although precision would be hard when the contact is first made), I guess what matters in those contexts is the point where the contact is lifted. I'm wondering though wrt wheels, values 0 and 71 are physically too close, but would make a big difference if absolute values are used there. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
On Thu, May 22, 2014 at 1:17 AM, Chandler Paul thatsly...@gmail.com wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho wrote: Hey there!, Here's a few patches to have libinput handle events from tablets, these devices are basically pointer devices, with a varying range of extra buttons (either stylus or pad buttons), and extra ABS_* axes. These devices also often offer information about the stylus in use, and its BTN_TOOL_* codes. So I've gone for reusing and extending libinput_event_pointer, adding extra libinput_pointer_axis values, and adding an axis_frame event to mark the end of a set of simultaneous axis changes, and a tool_update event to mark tool changes (and delimit proximity). These features are only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. I'm with Peter on splitting these up. It seems kind of inconsistent with the rest of libinput (with what I've gathered, anyway). A tablet-specific event sounds interesting too, but I feel like compressing all of the axis changes into. For now I'm going to work on having all the axis changes reported as separate POINTER_AXIS events. Caveats: * Many of these devices have also tactile strips or wheels, but these are unhandled so far... On the devices I've got available for testing, current kernel support seems varyingly inconsistent: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it We already agree with Wacom that it's the proper time to change stuffs in the kernel. I am currently working on it when I find some time, and I would appreciate any inputs on how things should be done. For example, the more I think of it, the more I think the tool ID does not make sense in the wacom kernel driver. This is used to multiplex the different stylus, mice, pads, through one only device, but it introduces a lot of problems. Not speaking that later on, Xorg splits those in physical devices. I know we are talking about Wayland, but given that we are building the protocol here, I think we should also think at what could be done in the kernel. Anyway, I was thinking at reporting several input devices for one Wacom (per stylus/eraser/mouse/pad - still not sure if I have to split the different stylus) so that there is no more multiplexing of the events and no difficult states to keep track to. Basically Lyude, just tell me your dreams (or keep track of them while writing the Wayland part) and we can start implementing them :) Cheers, Benjamin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
On Wed, May 21, 2014 at 10:17 PM, Chandler Paul thatsly...@gmail.com wrote: Hi! Sorry this took so long to write, I've been spending a lot of my time recently trying to understand the libinput code and all of that good stuff, and I wanted to make sure I had a decent understanding of it before I actually wrote up a response. On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho wrote: Hey there!, Here's a few patches to have libinput handle events from tablets, these devices are basically pointer devices, with a varying range of extra buttons (either stylus or pad buttons), and extra ABS_* axes. These devices also often offer information about the stylus in use, and its BTN_TOOL_* codes. So I've gone for reusing and extending libinput_event_pointer, adding extra libinput_pointer_axis values, and adding an axis_frame event to mark the end of a set of simultaneous axis changes, and a tool_update event to mark tool changes (and delimit proximity). These features are only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. I'm with Peter on splitting these up. It seems kind of inconsistent with the rest of libinput (with what I've gathered, anyway). A tablet-specific event sounds interesting too, but I feel like compressing all of the axis changes into. For now I'm going to work on having all the axis changes reported as separate POINTER_AXIS events. Caveats: * Many of these devices have also tactile strips or wheels, but these are unhandled so far... On the devices I've got available for testing, current kernel support seems varyingly inconsistent: - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max are 0..4096, but the reported values are 1,2,4,8,16... So effectively a log2 scale, or more graphically a bit shifting over a bunch of 0s, which is somewhat more resembling to the physical action on the strip. Since I'm on a deadline for this and making changes to this in the kernel would take too long, I don't think I'm going to advocate for changing this behavior right now. Although I do agree that eventually it should be changed. Graphically, a bit moving across a field like that makes sense, but I think that would be a difficult value to make practical use of in an application without changing it to a simple 1-13 value. If I get far enough that I can start implementing support for tactile strips and all those other fancy features some of these tablets have I might have it convert the values for tactile strips like that to something more usable by default and leave the other axes as-is. I'm curious to hear Ping and Jason's opinion on this though, and what kind of advantages - Another device has one wheel, reported through ABS_WHEEL. Even though min/max are reported as [0..1023], on interaction it goes [0..71] (funky range too) We could just forward this as-is, but seems hindering enough to do anything useful with those unless that behavior is corrected. When supported, IMO it'd make sense to have those axes behave similar to scroll axes, so the axis value increments or decrements depending on the direction. I'm not sure if there would be cases where the absolute value matters here? * One thing worth noting is that axes are currently normalized, to [-1..1] for stylus tilt, and [0..1] for everything else. I remember Peter's tablet wayland protocol proposal basically forwarded input_absinfo, this might not be fully compatible with that, although TBH I'm unsure clamping/normalization should take place so high in the stack... I'm with Peter on this actually. If the axes were used for something else I might approve of normalization in libinput but I think having absolute values fits more of the use cases for the extra axes found on many tablets, especially since Ping said that some of Wacom's in-house applications actually need these. I do think however, that maybe we should consider clamping axis values with libinput even if we don't normalize the axes by default. I've forked libinput and I have a branch where I'm fixing up the patches Carlos sent in based on the feedback from Peter. You can find it here: https://github.com/Lyude1337/libinput/tree/carlos_cleanup The history is messy on this, but once this is ready to get sent in as actual patches I'll be rebasing the history. Right now I've removed normalization from my branch, but if someone brings up a good reason to actually have libinput handle that then I can revert the change. Another thing I'm considering regarding this is just having libinput provide functions/macros for normalizing the values so applications can normalize the values easily if they want. The way I see it is that we want to allow all of the axes to be used how they were meant used. If Wacom isn't normalizing the values in their in-house applications I don't think we should either. Again though, I'm curious to hear
Re: [PATCH libinput 0/24] Tablet support
On Thu, May 22, 2014 at 4:55 PM, Carlos Garnacho carl...@gnome.org wrote: Hi Ping! On lun, 2014-04-21 at 18:03 -0700, Ping Cheng wrote: Benjamin is right. Those are absolute values. Most Linux applications do not use those extra values. But, there are in-house applications need those values. I'll have to ask around to give you some use cases if you are interested. Very late reply, but... I would certainly find some usecases interesting. When I visited some studios a while ago, I saw artists assign functions to those wheels and strips. But, I don't remember exactly what they use. Duh... For strips, I see this making sense (although precision would be hard when the contact is first made), I guess what matters in those contexts is the point where the contact is lifted. I'm wondering though wrt wheels, values 0 and 71 are physically too close, but would make a big difference if absolute values are used there. I guess the point is: developers can convert absolute value to relative. But, they can not convert relative back to absolute. So, if we have absolute value, it'd be better to keep it. It offers more option to application developers. Ping ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/4] test: disable CK_FORK for the valgrind runs
I'm not sure what exactly is happening here, but while valgrind seems to run fine in normal mode, the build from make distcheck fails with rather random errors. Disabling CK_FORK seems to help, but more investigation is needed. Meanwhile, this makes distcheck succeed again. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- test/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile.am b/test/Makefile.am index bfbbc96..b8de15c 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -101,7 +101,7 @@ VALGRIND_FLAGS=--leak-check=full \ --suppressions=$(srcdir)/valgrind.suppressions valgrind: - $(MAKE) check-TESTS LOG_COMPILER=$(VALGRIND) LOG_FLAGS=$(VALGRIND_FLAGS) + $(MAKE) check-TESTS LOG_COMPILER=$(VALGRIND) LOG_FLAGS=$(VALGRIND_FLAGS) CK_FORK=no check: valgrind -- 1.9.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/4] test: restore log priority after each test
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/log.c | 12
1 file changed, 12 insertions(+)
diff --git a/test/log.c b/test/log.c
index 0c5508f..b8cc767 100644
--- a/test/log.c
+++ b/test/log.c
@@ -74,6 +74,7 @@ END_TEST
START_TEST(log_handler_invoked)
{
struct libinput *li;
+ enum libinput_log_priority pri = libinput_log_get_priority();
libinput_log_set_priority(LIBINPUT_LOG_PRIORITY_DEBUG);
libinput_log_set_handler(simple_log_handler, NULL);
@@ -86,12 +87,14 @@ START_TEST(log_handler_invoked)
log_handler_called = 0;
libinput_destroy(li);
+ libinput_log_set_priority(pri);
}
END_TEST
START_TEST(log_userdata_NULL)
{
struct libinput *li;
+ enum libinput_log_priority pri = libinput_log_get_priority();
libinput_log_set_priority(LIBINPUT_LOG_PRIORITY_DEBUG);
libinput_log_set_handler(simple_log_handler, NULL);
@@ -104,12 +107,16 @@ START_TEST(log_userdata_NULL)
log_handler_called = 0;
libinput_destroy(li);
+
+ libinput_log_set_priority(pri);
+ libinput_log_set_priority(pri);
}
END_TEST
START_TEST(log_userdata)
{
struct libinput *li;
+ enum libinput_log_priority pri = libinput_log_get_priority();
libinput_log_set_priority(LIBINPUT_LOG_PRIORITY_DEBUG);
libinput_log_set_handler(simple_log_handler, li);
@@ -122,12 +129,14 @@ START_TEST(log_userdata)
log_handler_called = 0;
libinput_destroy(li);
+ libinput_log_set_priority(pri);
}
END_TEST
START_TEST(log_handler_NULL)
{
struct libinput *li;
+ enum libinput_log_priority pri = libinput_log_get_priority();
libinput_log_set_priority(LIBINPUT_LOG_PRIORITY_DEBUG);
libinput_log_set_handler(NULL, NULL);
@@ -141,12 +150,14 @@ START_TEST(log_handler_NULL)
libinput_log_set_handler(simple_log_handler, NULL);
libinput_destroy(li);
+ libinput_log_set_priority(pri);
}
END_TEST
START_TEST(log_priority)
{
struct libinput *li;
+ enum libinput_log_priority pri = libinput_log_get_priority();
libinput_log_set_priority(LIBINPUT_LOG_PRIORITY_ERROR);
libinput_log_set_handler(simple_log_handler, NULL);
@@ -164,6 +175,7 @@ START_TEST(log_priority)
log_handler_called = 0;
libinput_destroy(li);
+ libinput_log_set_priority(pri);
}
END_TEST
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/4] Replace log_bug with per-component bug macros
When we knowingly hit a bug, we should know what the bug is caused by. Log
that in a standardized fashion.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 8
src/evdev.c | 8
src/libinput-private.h | 4 +++-
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 65fa21b..a3220c5 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -365,8 +365,8 @@ tp_process_button(struct tp_dispatch *tp,
/* Ignore other buttons on clickpads */
if (tp-buttons.is_clickpad e-code != BTN_LEFT) {
- log_bug(received %s button event on a clickpad (kernel
bug?)\n,
- libevdev_event_code_get_name(EV_KEY, e-code));
+ log_bug_kernel(received %s button event on a clickpad\n,
+ libevdev_event_code_get_name(EV_KEY, e-code));
return 0;
}
@@ -416,10 +416,10 @@ tp_init_buttons(struct tp_dispatch *tp,
if (libevdev_has_event_code(device-evdev, EV_KEY, BTN_MIDDLE) ||
libevdev_has_event_code(device-evdev, EV_KEY, BTN_RIGHT)) {
if (tp-buttons.is_clickpad)
- log_bug(clickpad advertising right button (kernel
bug?)\n);
+ log_bug_kernel(clickpad advertising right button\n);
} else {
if (!tp-buttons.is_clickpad)
- log_bug(non clickpad without right button (kernel
bug)?\n);
+ log_bug_kernel(non clickpad without right button?\n);
}
width = abs(device-abs.max_x - device-abs.min_x);
diff --git a/src/evdev.c b/src/evdev.c
index 08a18fd..6e0bb93 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -137,8 +137,8 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
break;
if (device-mt.slots[slot].seat_slot != -1) {
- log_bug(%s: Driver sent multiple touch down for the
- same slot, device-devnode);
+ log_bug_kernel(%s: Driver sent multiple touch down for
the
+ same slot, device-devnode);
break;
}
@@ -186,8 +186,8 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
break;
if (device-abs.seat_slot != -1) {
- log_bug(%s: Driver sent multiple touch down for the
- same slot, device-devnode);
+ log_bug_kernel(%s: Driver sent multiple touch down for
the
+ same slot, device-devnode);
break;
}
diff --git a/src/libinput-private.h b/src/libinput-private.h
index dc1d590..61cdc79 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -84,7 +84,9 @@ struct libinput_source;
#define log_debug(...) log_msg(LIBINPUT_LOG_PRIORITY_DEBUG, __VA_ARGS__)
#define log_info(...) log_msg(LIBINPUT_LOG_PRIORITY_INFO, __VA_ARGS__)
#define log_error(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, __VA_ARGS__)
-#define log_bug(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, BUG: __VA_ARGS__)
+#define log_bug_kernel(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, kernel bug:
__VA_ARGS__)
+#define log_bug_libinput(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, libinput
bug: __VA_ARGS__);
+#define log_bug_client(...) log_msg(LIBINPUT_LOG_PRIORITY_ERROR, client bug:
__VA_ARGS__);
void
log_msg(enum libinput_log_priority priority, const char *format, ...);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: remove redundant 'the' in description
Signed-off-by: Silvan Jegen s.je...@gmail.com --- protocol/wayland.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 22eb6e7..113c7b7 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -550,8 +550,8 @@ The current and pending input regions of the icon wl_surface are cleared, and wl_surface.set_input_region is ignored until the wl_surface is no longer used as the icon surface. When the use - as an icon ends, the the current and pending input regions - become undefined, and the wl_surface is unmapped. + as an icon ends, the current and pending input regions become + undefined, and the wl_surface is unmapped. /description arg name=source type=object interface=wl_data_source allow-null=true/ arg name=origin type=object interface=wl_surface/ -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
