On Fri, Jul 31, 2015 at 02:37:52PM +0800, Jonas Ådahl wrote:
> On Fri, Jul 31, 2015 at 04:19:03PM +1000, Peter Hutterer wrote:
> > There is no need here to use µs since we're just handling speeds/thresholds,
> > not actual events where a ms granularity can be too high.
> >
> > Moving back to ms le
On Fri, Jul 31, 2015 at 04:19:03PM +1000, Peter Hutterer wrote:
> There is no need here to use µs since we're just handling speeds/thresholds,
> not actual events where a ms granularity can be too high.
>
> Moving back to ms lets us drop a bunch of zeroes that clutter up the code, and
> since the
if wl_resource_create() fails to create the resource (i.e.
client->display_resource) and returns NULL.
For such case, the patch will post the message "no memory" for that client in
"wl_resource_post_error()" and after that
it will return at below check.
if (!client->display_resource)
return
Signed-off-by: Peter Hutterer
---
src/filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/filter.c b/src/filter.c
index f8f9409..54ae397 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -493,8 +493,8 @@ touchpad_lenovo_x230_accel_profile(struct motion_filter
*filt
Now using µs.
Signed-off-by: Peter Hutterer
---
tools/ptraccel-debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ptraccel-debug.c b/tools/ptraccel-debug.c
index 1496763..b0867db 100644
--- a/tools/ptraccel-debug.c
+++ b/tools/ptraccel-debug.c
@@ -147,12 +147,1
There is no need here to use µs since we're just handling speeds/thresholds,
not actual events where a ms granularity can be too high.
Moving back to ms lets us drop a bunch of zeroes that clutter up the code, and
since the acceleration functions are a bit magic anyway, having the various
1000.0 f
On Thu, Jul 30, 2015 at 03:40:50PM +0200, Marek Chalupa wrote:
> On 07/30/2015 04:33 AM, Jonas Ådahl wrote:
> >One of the principles of Wayland is that object creation never fails. If
> >the object cannot be created, it should be reported as a protocol error
> >and an offending client should be ter
drm, fbdev, rpi and wayland backends are unnecessarily destroying
renderer and output before executing weston_compositor_shutdown()
Signed-off-by: Dawid Gajownik
---
src/compositor-drm.c | 1 -
src/compositor-fbdev.c | 5 +
src/compositor-rpi.c | 7 ++-
src/compositor-waylan
On Thu, Jul 30, 2015 at 10:47 PM, Bryce Harrington
wrote:
> Mind re-posting the patch, with updated changelog accounting for
> dropping the redundant renderer destruction.
>
> I did a quick look through the other compositor codes in case they
> contained similar code, but didn't spot anything. Di
On Thu, Jul 30, 2015 at 10:00:29AM -0300, Dawid Gajownik wrote:
> Hi Ryo,
>
> good catch. I missed this one.
Mind re-posting the patch, with updated changelog accounting for
dropping the redundant renderer destruction.
I did a quick look through the other compositor codes in case they
contained
On Thu, Jul 30, 2015 at 04:42:00PM +0200, Marek Chalupa wrote:
> scanner does not complain if we put into version attribute
> things like -1 1x 1:3 etc.
>
> Signed-off-by: Marek Chalupa
Reviewed-by: Bryce Harrington
Yep, nice improvement. Pushed to trunk:
To ssh://git.freedesktop.org/git/way
On Thu, Jul 30, 2015 at 05:58:05PM -0700, Bryce Harrington wrote:
> On Thu, Jul 30, 2015 at 03:07:20PM +0200, Marek Chalupa wrote:
> > wrap creating and initializing objects (structures)
> > into functions and use them in the code.
> >
> > v2. make create_.* functions consistent
> > (no func w
When output can't be created in foo_backend_create_output(),
weston_output_destroy() is called without executing
weston_compositor_add_output(). In such a case output->link is not initialized
and causes application crash on wl_list_remove(&output->link).
This problem happens when drm, fbdev, rdp,
On Thu, Jul 30, 2015 at 03:07:22PM +0200, Marek Chalupa wrote:
> Use xzalloc instead of xmalloc. This allows us to get rid
> of manual initializing the memory to 0s and the code is
> shorter and cleaner
>
> Suggested by Bryce Harrington
>
> Signed-off-by: Marek Chalupa
Reviewed-by: Bryce Harrin
On Thu, Jul 30, 2015 at 03:07:21PM +0200, Marek Chalupa wrote:
> Free all the memory we have allocated during running.
>
> v2.: split creating objects and getting rid of leaks
> into two patches
>
> move check for NULL description into free_description
>
> v3.: rebase after previous pa
On Thu, Jul 30, 2015 at 03:07:20PM +0200, Marek Chalupa wrote:
> wrap creating and initializing objects (structures)
> into functions and use them in the code.
>
> v2. make create_.* functions consistent
> (no func will return NULL)
>
> Signed-off-by: Marek Chalupa
Looks good
Reviewed-by: B
On Thu, Jul 30, 2015 at 04:34:14PM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-07-15 14:31, Hans de Goede wrote:
> >Hi,
> >
> >On 30-07-15 08:11, Peter Hutterer wrote:
> >>Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
> >>should also disable gestures. The data doesn't m
On Thu, Jul 30, 2015 at 09:54:25AM -0700, Bill Spitzak wrote:
> On Thu, Jul 30, 2015 at 7:45 AM, Hans de Goede wrote:
>
> +/* This device has a terrible 2fg resolution, but only for the
> >>> + * second finger, causing scroll jumps when we use the touch points
> >>> + * properly. The
On Thu, Jul 30, 2015 at 04:45:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-07-15 14:33, Hans de Goede wrote:
> >Hi,
> >
> >On 30-07-15 08:11, Peter Hutterer wrote:
> >>The first finger is accurate, it's just the second finger that is imprecise,
> >>so we can't handle it as a true touch. Instea
On Thu, Jul 30, 2015 at 02:29:18PM +0200, Hans de Goede wrote:
> Hi,
>
> On 30-07-15 08:11, Peter Hutterer wrote:
> >Not all multi-finger touchpads are able to reliably produce gestures, so make
> >it optional. This patch just adds a boolean (currently always true) that gets
> >set on touchpad ini
Hello everyone,
We are 1.5 months away from XDC and 20 days away from the proposals
deadline[1]!
If you did not manage to secure funding from your company but still
think you could benefit the community by giving a talk, we encourage you
to send an email to the board of X.Org with your talk
On Thu, Jul 30, 2015 at 12:43:29PM -0700, Bill Spitzak wrote:
> Okay then, but that brings me back to my original question:
>
> If a client does not ask for a particular gesture (by not creating the
> protocol object that delivers that gesture's events), and the user makes
> that gesture, does the
Okay then, but that brings me back to my original question:
If a client does not ask for a particular gesture (by not creating the
protocol object that delivers that gesture's events), and the user makes
that gesture, does the client get anything?
I was trying to solve a huge problem that will ma
On Thu, Jul 30, 2015 at 6:40 AM, Marek Chalupa wrote:
> -This request only takes effect if the seat has the pointer
>> -capability.
>> + This request always takes effect, but the created wl_pointer
>> object
>> + will only emit events as long as the seat has the point
On Thu, Jul 30, 2015 at 7:45 AM, Hans de Goede wrote:
+/* This device has a terrible 2fg resolution, but only for the
>>> + * second finger, causing scroll jumps when we use the touch points
>>> + * properly. The first finger resolution is accurate though, so
>>> + * we simply pre
Hi,
On 30-07-15 14:33, Hans de Goede wrote:
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch b
scanner does not complain if we put into version attribute
things like -1 1x 1:3 etc.
Signed-off-by: Marek Chalupa
---
src/scanner.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index b0e9ef7..9b41ae4 1
Hi,
On 30-07-15 14:31, Hans de Goede wrote:
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
I think we should wait with doing this until the scr
Hi,
On 07/30/2015 04:33 AM, Jonas Ådahl wrote:
One of the principles of the Wayland protocol is that object creation
always succeeds. If the server for some reason cannot create a valid
object as a response to some request, this would typically be caused by
a protocol violation and in such cases
On 07/30/2015 04:33 AM, Jonas Ådahl wrote:
One of the principles of Wayland is that object creation never fails. If
the object cannot be created, it should be reported as a protocol error
and an offending client should be terminated.
A current violation to this principle is the input device crea
Free all the memory we have allocated during running.
v2.: split creating objects and getting rid of leaks
into two patches
move check for NULL description into free_description
v3.: rebase after previous patch fixes
Signed-off-by: Marek Chalupa
---
src/scanner.c | 106 +
Use xzalloc instead of xmalloc. This allows us to get rid
of manual initializing the memory to 0s and the code is
shorter and cleaner
Suggested by Bryce Harrington
Signed-off-by: Marek Chalupa
---
src/scanner.c | 83 ---
1 file changed, 40
wrap creating and initializing objects (structures)
into functions and use them in the code.
v2. make create_.* functions consistent
(no func will return NULL)
Signed-off-by: Marek Chalupa
---
src/scanner.c | 164 +++---
1 file changed, 11
Hi Ryo,
good catch. I missed this one.
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index a8e63e1..70f0939 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2035,12 +2035,6 @@ err_compositor:
static void
wayland_backend_destroy(struct wayland_backend *
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch bits for second finger
handling.
Two-finger sc
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
I think we should wait with doing this until the scroll situation is more
clear, see my last comme
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
Unlike ALPS and Synaptics semi-mt touchpads, the Elantech touchpads appear to
be precise enough to allow a smaller motion threshold before we decide on the
type of gesture (pinch vs scroll).
https://bugs.freedesktop.org/show_bug.cgi?id=91475
Signed-
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
Not all multi-finger touchpads are able to reliably produce gestures, so make
it optional. This patch just adds a boolean (currently always true) that gets
set on touchpad init time, i.e. it is not run-time configurable.
Three and four-finger gesture
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
That's where we set the pointer cap too.
No functional changes.
Signed-off-by: Peter Hutterer
LGTM: Reviewed-by: Hans de Goede
Regards,
Hans
---
src/evdev-mt-touchpad.c | 1 +
src/evdev.c | 1 -
2 files changed, 1 insertion(+)
Hi,
On 30-07-15 08:11, Peter Hutterer wrote:
To avoid duplication
Signed-off-by: Peter Hutterer
LGTM: Reviewed-by: Hans de Goede
Regards,
Hans
---
test/litest.h | 93 ++
test/touchpad-buttons.c | 72 +++-
test/touchpad-tap.c |
Hey,
ping
(not sure if in-reply-to will work, so here's a link too
http://lists.x.org/archives/xorg-devel/2014-July/043080.html)
I pinged this patch for two reasons:
1) it fixes a bug https://bugzilla.gnome.org/show_bug.cgi?id=752165
2) [for wayland-devel] The order of modifier event and the k
41 matches
Mail list logo
