On Tue, May 20, 2014 at 01:12:32PM -0700, Bill Spitzak wrote:
> On 05/19/2014 11:55 PM, Pekka Paalanen wrote:
>
> >What is the target audience of the build guide?
>
> Somebody who wants to contribute to wayland.
>
> I have been writing Linux software in C/C++ and OpenGL for about 20 years
> now,
This patch reimplements the simple smooth pointer acceleration profile
from X.org xserver. The algorithm is identical to the classic profile
with a non-zero pointer acceleration threshold.
When support for changable parameters is in place, to get a pointer
acceleration the same as the default clas
Alter the so far hard coded parameters a bit to make the pointer
acceleration profile accelerate the pointer movement a bit more than
before.
Signed-off-by: Jonas Ådahl
---
src/evdev-mt-touchpad.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
> Behalf Of Bill Spitzak
> Sent: Tuesday, May 20, 2014 2:03 PM
> To: wayland-devel@lists.freedesktop.org
> Subject: Re: Wayland and Weston 1.5.0 is released
>
> On 05/20/2014 01:12 PM, Krist
On 05/20/2014 01:12 PM, Kristian Høgsberg wrote:
• The weston input stack was split out as a new library, libinput.
Weston can be configured to link to libinput for input but defaults
to the built in input code for now. As the libinput API
stabilizes, we'll remove the in-weston in
On 05/19/2014 11:55 PM, Pekka Paalanen wrote:
What is the target audience of the build guide?
Somebody who wants to contribute to wayland.
I have been writing Linux software in C/C++ and OpenGL for about 20
years now, including making my own autoconf scripts. I have to tell you
that these d
Hi,
I tagged 1.5.0 of Wayland and Weston and uploaded tar balls last
night. Tarballs available from
http://wayland.freedesktop.org/releases.html as usual. Magic SHA1
number for the tags and tar balls:
bace08b4a531ea4b80b4cf4e953320bc48ed7efe wayland-1.5.0.tar.xz
3ac62cd6b6012f40e37b1bd7fc1
From: Peter Hutterer
This is a slightly fancier implementation than the simplest model and ported
over from libtouchpad. It implements a state machine for the software buttons
with left and right buttons currently implemented. Buttons are oriented
left-to-right, in a horizontal bar. No random but
This is no longer needed now that we take the button area and pinned fingers
into account.
Signed-off-by: Hans de Goede
Reviewed-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index fc4a4f7
From: Peter Hutterer
Signed-off-by: Peter Hutterer
Signed-off-by: Hans de Goede
Reviewed-by: Hans de Goede
---
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
We already check for old != current everywhere, so this is not needed;
And in tp_post_softbutton_buttons we want to do delay button down reporting if
we don't have touch info yet in which case this check actually gets in the way.
Signed-off-by: Hans de Goede
Reviewed-by: Peter Hutterer
---
src/
It is possible for a click to get reported before any related touch events
get reported, here is the relevant part of an evemu-record session on a T440s:
E: 3.985585 # SYN_REPORT (0) --
E: 3.997419 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1
E: 3
From: Peter Hutterer
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
Signed-off-by: Hans de Goede
Reviewed-by: Jo
Signed-off-by: Hans de Goede
Reviewed-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index f5e0300..fc4a4f7 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt
From: Peter Hutterer
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
We store timestamps in ms since system boot (CLOCK_MONOTONIC). This will wrap
after circa 50 days.
I've considered making our code wrapping safe, but that won't work. We also
use our internal timestamps to program timer-fds for timeouts. And we store
ms in a single integer but the kernel uses 2 in
From: Peter Hutterer
To avoid having a button left press and a button right release if the number
of fingers changes.
Signed-off-by: Peter Hutterer
Signed-off-by: Hans de Goede
Reviewed-by: Jonas Ådahl
Reviewed-by: Hans de Goede
---
src/evdev-mt-touchpad-buttons.c | 22 +
From: Peter Hutterer
No real effect, just for safety
Signed-off-by: Peter Hutterer
Signed-off-by: Hans de Goede
Reviewed-by: Jonas Ådahl
Reviewed-by: Hans de Goede
---
src/evdev-mt-touchpad-tap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad-ta
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_S
Hans de Goede Tue, 15 Apr 2014 05:29:33 -0700
Hi All,
Here is the 3th version of the clickpad-improvements patch-set Peter
and I have been working on.
Changes in v2:
-"after a click, lock the finger to its current position"
Pin all fingers until they move more then the threshold in
-"touchpad:
From: Peter Hutterer
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
Signed-off-by: Hans de Goede
Reviewed-by: Hans de Goede
---
src/Mak
From: Peter Hutterer
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 al
And warn if INPUT_PROP_BUTTONPAD mismatches right/middle buttons presence.
Also fix the bcm5974 to properly advertise INPUT_PROP_BUTTONPAD.
Signed-off-by: Hans de Goede
Reviewed-by: Peter Hutterer
---
src/evdev-mt-touchpad-buttons.c | 34 ++
src/evdev-mt-touchpa
Signed-off-by: Hans de Goede
Reviewed-by: Peter Hutterer
---
src/evdev-mt-touchpad-buttons.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index c35d14a..75e1ff7 100644
--- a/src/evdev-mt-touchpad-butto
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
Reviewed-by: Peter Hutterer
---
src/evdev-mt-touchpad-buttons.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a
On Tue, May 20, 2014 at 2:55 AM, Pekka Paalanen wrote:
> On Mon, 19 May 2014 20:31:28 -0700
> Bill Spitzak wrote:
>
> >
> >
> > On 05/19/2014 12:39 AM, Pekka Paalanen wrote:
> > > On Fri, 16 May 2014 13:43:50 -0700
> > > spit...@gmail.com wrote:
> > >
> > >> From: spitzak
> > >>
> > >> This is
Version 2 of the patch makes the following changes:
• The patch is reordered to be on top of the patch to handle
wl_output.release so that it doesn't need to have a dummy marker for
zombifying without a destructor.
• The destructor opcode is stored in the implementation pointer rather
than
Here is a version two of the patch which is just needed so that the
patches can be reordered and this can come before the patch to handle
zombies.
--- >8 --- (use git am --scissors to automatically chop here)
The wl_output.release request is now handled. It just causes the
resourc
Here is a version two of the patch which moves the macro to
wayland-server.h and fixes a typo in the docs.
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
This adds a macro called WL_REQUEST_OPCODE which takes the name of the
struct for the interface and the
This gets the implementation for a resource that was set in the
implementation argument of wl_resource_set_implementation or
wl_resource_set_dispatcher. This is mostly useful in conjuction with a
dispatcher which may want to dispatch via the implementation pointers
or just store some extra informat
2014-04-25 21:43 に Pekka Paalanen さんは書きました:
On Tue, 18 Mar 2014 23:57:32 +0900
Nobuhiko Tanibata wrote:
Signed-off-by: Nobuhiko Tanibata
---
Changes for v2, v3 and v4
- nothing. Version number aligned to the first patch
Changes for v5
- support weston-dnd-ivi to verify wl_pointer::set_c
2014-04-25 19:41 に Pekka Paalanen さんは書きました:
On Mon, 17 Mar 2014 15:31:09 +0900
Nobuhiko Tanibata wrote:
Signed-off-by: Nobuhiko Tanibata
---
Changes for v2:
- squash Makefile to this patch
Changes for v3 and v4
- nothing. Version number aligned to the first patch
ivi-shell/Makefile.am
Hi,
On 04/24/2014 07:21 AM, Peter Hutterer wrote:
> On Tue, Apr 15, 2014 at 02:28:07PM +0200, Hans de Goede wrote:
>> We don't want touches in the button area to cause the pointer to move, add
>> a tp_button_touch_active function which the main code in evdev-mt-touchpad
>> can call to see if a tou
2014-04-25 20:55 に Pekka Paalanen さんは書きました:
On Thu, 20 Mar 2014 16:00:57 +0900
Nobuhiko Tanibata wrote:
This is launched from hmi-controller by using hmi_client_start and
create a
pthread.
The basic flow is as followed,
1/ create pthread
2/ read configuration from weston.ini.
3/ draw png fil
2014-04-25 20:38 に Pekka Paalanen さんは書きました:
On Mon, 17 Mar 2014 15:28:22 +0900
Nobuhiko Tanibata wrote:
The library is used to manage layout of surfaces/layers. Layout change
is
triggered by ivi-hmi-controller protocol, ivi-hmi-controller.xml. A
reference
how to use the protocol, see hmi-con
Jason Ekstrand writes:
> The destructor passed in here should be 0, why is it ~0? Also, it
> might be a good idea to throw it in a #define or enum for clarity.
The ~0 is meant to signify ‘there is no destructor’, ie, it's a fake
opcode that will never match a request. The reason is that I put th
Jason Ekstrand writes:
> Yeah, these are the wrong semantics. If they specify an output and it
> turns out to be a zombie, we should do nothing. A null output in
> wl_fullscreen_shell.present_surface means "put it somewhere". In the case
> of weston's implementation, it goes on all outputs. W
Jason Ekstrand writes:
> Ooh, I like this. I thought about having wayland-scanner emit more
> #defines, but this works rather nicely. One question: do we want it in
> wayland-util or wayland-server? Putting it in wayland-util exposes it
> client-side as well.
> --Jason
Yeah, I agree, perhaps
38 matches
Mail list logo
