On clickpads, releasing the button usually causes some motion events. To avoid
erroneous movements, lock the finger into position on the up event and don't
allow for motion events until we move past a given threshold (currently 2% of
the touchpad diagonal).
Signed-off-by: Peter Hutterer
---
src/
This is about to become more complicated with the support for software button
areas. Move it to a separate file to have it logically grouped together.
No functional changes.
Signed-off-by: Peter Hutterer
---
src/Makefile.am | 1 +
src/evdev-mt-touchpad-buttons.c | 146 +
Signed-off-by: Peter Hutterer
---
doc/Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 31b673b..75fa98a 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,3 +1,5 @@
+EXTRA_DIST = touchpad-tap-state-machine.svg
+
if H
Apple touchpads don't have visible markings for the software button areas
that almost all other vendors use. OS X provides clickfinger behaviour
instead, where a click with two fingers on the touchpad generate a right
button click. Use that same behaviour in libinput.
For all other touchpads, use
To avoid having a button left press and a button right release if the number
of fingers changes.
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad-buttons.c | 22 +-
src/evdev-mt-touchpad.h | 1 +
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/
Immediately set the state to DEAD, waiting for the tap release to go back to
idle.
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad-tap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index bcc5700..863e004 10
No real effect, just for safety
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad-tap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index 5fa712f..bcc5700 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src
I still need to write some tests for the buttons, but I'd like people to
have a look at it already. Branch is also available from
https://github.com/whot/libinput/tree/wip/clickpad-improvements
Cheers,
Peter
___
wayland-devel mailing list
wayland-deve
A single-touch touchpad that provides BTN_TOOL_TRIPLETAP has 3 touches, etc.
There aren't a lot of these out there, but some touchpads don't have slots but
do provide two- or three-finger detection.
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 22 +-
1 file cha
On Thu, Mar 27, 2014 at 05:10:34PM +0100, Jonas Ådahl wrote:
> On Thu, Mar 27, 2014 at 08:48:02AM +1000, Peter Hutterer wrote:
> > Both functions accept a series of event types/codes tuples, terminated by
> > -1.
> > For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is
> > use
On Thu, Mar 27, 2014 at 10:19:50PM +0600, Alexander E. Patrakov wrote:
> Hello.
>
> This is a report of a touchpad firmware bug that I want you to work
> around in libinput. I found this bug while testing
> xf86-input-libinput. I guess that the synaptics driver already has a
> workaround, or the b
Signed-off-by: Peter Hutterer
---
This requires the uinput device creation patch I sent out yesterday.
test/litest-synaptics.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/test/litest-synaptics.c b/test/litest-synaptics.c
index d6aecc4..6df643c 100644
--- a/test/litest-synaptics.c
+++ b
A few functions only work on the base event but once we've converted to the
target event we can't go back. Casting works for now but that would expose
internal ABI.
Signed-off-by: Peter Hutterer
---
I got annoyed that I had to pass two arguments around or lose some
type-safety just to e.g. get th
Looks a bit excessive given how simple the base is but hey, we don't want to
ever break that bit. That'd be embarrassing.
And while we're at it make sure that the 'wrong' event getters return NULL for
each event.
Signed-off-by: Peter Hutterer
---
This requires the uinput device creation patch I
Remove compiler warning about signed/unsigned comparison. And while we're at
it, rename i to _i in the macro to avoid name clashes.
Signed-off-by: Peter Hutterer
---
src/libinput-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libinput-util.h b/src/libinput-util.h
Signed-off-by: Peter Hutterer
---
The main problem: valgrind is slow. I'm ok with taking the automatic hook
out and requiring a make valgrind separate call.
Makefile.am| 3 +++
configure.ac | 9 +++--
test/Makefile.am | 13 +
test/valgrin
We depend on device creation on the host system, having the tests run in
parallel runs a risk of random failure.
Ideally we'd just disable for the actual run target, but I couldn't figure out
how to do that.
Signed-off-by: Peter Hutterer
---
test/Makefile.am | 2 ++
1 file changed, 2 insertions
Signed-off-by: Peter Hutterer
---
I didn't end up needing this but it seems a nice to have. However, it does
lead to a discussion on how much of the device should we expose to the
caller through libinput.
Right now libinput hides virtually everthing but the sysname and even that
may not be enough
And redirect the log to stdout. libinput logs to stderr by default, but if
we're running with --verbose we want all msgs on the same stream.
Signed-off-by: Peter Hutterer
---
tools/event-debug.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/event-
Signed-off-by: Peter Hutterer
---
src/evdev-touchpad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index 65c5ea0..1a48441 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -454,7 +454,7 @@ fsm_timeout_handler(void *
>-Original Message-
>From: Pekka Paalanen [mailto:ppaala...@gmail.com]
>Sent: Thursday, March 27, 2014 9:06 PM
>To: Jasper St. Pierre
>Cc: Wang, Quanxian; wayland-devel@lists.freedesktop.org
>Subject: Re: weston: weston randr protocol for testing and configuration
>
>On Thu, 27 Mar 2014 0
Note:
Take user as developer or admin for weston randr discussion (in the following
discussion, I always think user as developer or admin).
>-Original Message-
>From: Pekka Paalanen [mailto:ppaala...@gmail.com]
>Sent: Thursday, March 27, 2014 6:35 PM
>To: Wang, Quanxian
>Cc: wayland-deve
Andrew,
Thanks for reviewing. Comments follow.
On Mar 27, 2014 7:02 AM, "Andrew Wedgbury"
wrote:
>
> Hi Jason,
>
> A few comments I have from trying out your fullscreen-shell changes:
>
>
> On Tue, 18 Mar 2014, Jason Ekstrand wrote:
>
>> +static struct ss_seat *
>> +ss_seat_create(struct shared_
On Thu, Mar 27, 2014 at 07:34:37PM +0600, Alexander E. Patrakov wrote:
> 2014-03-27 19:22 GMT+06:00 Alexander E. Patrakov :
>
> (regarding slow scrolling)
>
> > I don't think so. I have tried to reproduce the bug by hand. It still
> > exists, but ./tools/event-debug still picks the scrolling up
>
On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:
> Hi
Hi David
> On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita wrote:
> > - Added two new functions, xkb_state_key_get_utf{8,32}(). They
> > combine the operations of xkb_state_key_get_syms() and
> > xkb_keysym_to_utf{8,32}(), and
Hi
On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita wrote:
> - Added two new functions, xkb_state_key_get_utf{8,32}(). They
> combine the operations of xkb_state_key_get_syms() and
> xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
> (espcially for multiple-keysyms-per-level).
Sl
We've accumulated some changes and bug fixes, so here's a new release.
libxkbcommon 0.4.1
==
- Converted README to markdown and added a Quick Guide to the
documentation, which breezes through the most common parts of
xkbcommon.
Link: http://xkbcommon.org/doc/current/md_doc_q
On Thu, Mar 27, 2014 at 08:48:02AM +1000, Peter Hutterer wrote:
> Both functions accept a series of event types/codes tuples, terminated by -1.
> For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is used
> as a property to enable.
>
> The _abs function als takes an array of abs
I mean, I'm mostly talking about user configuration in the case of a
desktop, when the user wants to change the mode of the display.
Obviously, it would be best if we could detect hardware edge cases like
that where it's going on the fritz and showing a green tint automatically,
and simply not off
On Thu, 27 Mar 2014 08:31:34 -0400
"Jasper St. Pierre" wrote:
> I don't think the user really knows what refresh is either.
>
> I'm actually curious: is there a reason to ever expose different modes to
> the user that have the same width/height but different timings? What's the
> rationale for c
I don't think the user really knows what refresh is either.
I'm actually curious: is there a reason to ever expose different modes to
the user that have the same width/height but different timings? What's the
rationale for choosing one instead of the other? I know nothing about
display panels, kee
Hi Jason,
A few comments I have from trying out your fullscreen-shell changes:
On Tue, 18 Mar 2014, Jason Ekstrand wrote:
+static struct ss_seat *
+ss_seat_create(struct shared_output *so, uint32_t id)
+{
+ struct ss_seat *seat;
+
+ seat = zalloc(sizeof *seat);
+ if (seat == NULL)
On Thu, 27 Mar 2014 04:08:15 +
"Wang, Quanxian" wrote:
> Hi, Pq
>
> The information to identify the unique mode: width, height and refresh are
> enough? Not enough in theory. But is enough in real world. I have checked
> with xrandr. Read the following comment.
>
> Welcome any comment for
33 matches
Mail list logo
