[PATCH RFC libinput] filter: force touchpads to a fixed report rate

[Peter Hutterer]

From: Hans de Goede 

Some devices, specifically some bluetooth touchpads generate quite
unreliable timestamps for their events. The problem seems to be that
(some of) these touchpads sample at aprox 90 Hz, but the bluetooth stack
only communicates about every 30 ms (*) and then sends mutiple HID input
reports in one batch.

This results in 2-4 packets / SYNs every 30 ms. With timestamps really
close together. The finger coordinate deltas in these packets change by
aprox. the same amount between each packet when moving a finger at
constant speed. But the time deltas are e.g. 28 ms, 1 ms, 1 ms resulting
in calculate_tracker_velocity returning vastly different speeds for the
1st and 2nd packet, which in turn results in very "jerky" mouse pointer
movement.

*) Maybe it is waiting for a transmit time slot or some such.

This commit adds support for a fixed report rate on touchpads. We take the
assumption that a device with a fixed report rate will send events at that
rate but those events may be delayed by the kernel or accelerated following
some previous delay. Any timestamp that falls within the acceptable range (1.5
times the frequency) is set to the fixed report rate instead.

This does not affect the event timestamps, it only applies to pointer
acceleration.

Signed-off-by: Hans de Goede 
Signed-off-by: Peter Hutterer 
---
This replaces Hans' two patches in this thread.
Changes to Hans' patch:
- both patches squashed together
- instead of smoothing threshold/value assume a fixed report rate
- save the fixed timestamp in the trackers

Hans, please give this one a try. btw, what touchpad are we talking about
here?

It's the same principle, but instead of smoothing I figured we should just
go all the way and encode the report rate, assume that's what the device
will produce even if the kernel or some stack adds delays and adjust the
timestamps for that report rate. There's a fixme that needs to be addressed 
still
and obviously the 82Hz value measured on my device won't work for everyone
so it needs to move into a udev property.

But please give it try and let me know what you think

 src/evdev-mt-touchpad.c |  2 +-
 src/filter.c| 53 +
 src/filter.h|  3 ++-
 tools/ptraccel-debug.c  |  2 +-
 4 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 0a4f4d98..b2968444 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -2140,7 +2140,7 @@ tp_init_accel(struct tp_dispatch *tp)
tp->device->model_flags & EVDEV_MODEL_LENOVO_X220_TOUCHPAD_FW81)
filter = 
create_pointer_accelerator_filter_lenovo_x230(tp->device->dpi);
else
-   filter = 
create_pointer_accelerator_filter_touchpad(tp->device->dpi);
+   filter = 
create_pointer_accelerator_filter_touchpad(device->dpi, 82);
 
if (!filter)
return false;
diff --git a/src/filter.c b/src/filter.c
index 7c500f87..d470d633 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -176,6 +176,10 @@ struct pointer_accelerator {
double accel;   /* unitless factor */
double incline; /* incline of the function */
 
+   /* For smoothing timestamps from devices with unreliable timing */
+   unsigned int report_rate; /* in Hz */
+   uint64_t report_rate_tdelta; /* in us */
+
int dpi;
 };
 
@@ -208,6 +212,30 @@ feed_trackers(struct pointer_accelerator *accel,
trackers[i].delta.y += delta->y;
}
 
+   /* If we have a fixed report rate on the device we don't take the
+* kernel timestamps, they may be inaccurate.  Instead, anything
+* less than 1.5 times the scanout rate is forced to that scanout
+* rate.
+*/
+   if (accel->report_rate != 0) {
+   uint64_t last_time;
+   int tdelta = 0;
+
+   last_time = trackers[accel->cur_tracker].time;
+   /* FIXME: if last_time >= time, the device's report_rate is
+  higher than the one we set. This can be ignored (e.g.
+  bluetooth touchpad that send 3 packets every 30ms,
+  but packets two and three have a delta of 1ms) or it can
+  become a problem (e.g. 80Hz set but 100Hz reported, our
+  timestamps will get more and more out of sync)
+*/
+   if (last_time < time)
+   tdelta = time - last_time;
+
+   if (tdelta < accel->report_rate_tdelta * 1.5)
+   time = last_time + tdelta;
+   }
+
current = (accel->cur_tracker + 1) % NUM_POINTER_TRACKERS;
accel->cur_tracker = current;
 
@@ -227,14 +255,18 @@ tracker_by_offset(struct pointer_accelerator *accel, 
unsigned int offset)
 }
 
 static double

Re: [PATCH weston 1/2] text-backend: Allow client hiding of input panel

[Silvan Jegen]

Hi Joshua

On Wed, Jul 05, 2017 at 08:58:51AM -0500, Joshua Watt wrote:
> On Sat, 2017-06-24 at 16:03 -0500, Joshua Watt wrote:
> > Previously, the hide_input_panel and show_input_panel messages for
> > the text
> > input protocol were limited to specific cases, such as showing the
> > panel on
> > activation, or making the panel visible after activation. Now,
> > clients are
> > allowed to toggle the panel visiblity at will as long as they are the
> > currently
> > active client
> > 
> > Signed-off-by: Joshua Watt 
> > ---
> >  compositor/text-backend.c | 22 --
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> Ping?

I have tested your two patches locally and can confirm that they compile
and run.

Letting the user toggle the visibility of the input panel with a click
(in the --click-to-show case) seems like a good change to me. I doubt
that there are any strong opinions on this though...


Cheers,

Silvan

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/3] compositor-rdp: fix leak of frame bitmap in raw mode

[Hardening]

Le 06/07/2017 à 12:06, Olivier Blin a écrit :
> In rdp_peer_refresh_raw(), cmd->bitmapData was reallocated, but never freed.
> 
> The cmd content (actually peer->update->surface_bits_command) was
> re-initialized to zero at the beginning of the function, losing the
> pointer to the previously allocated bitmap data.
> 
> Move the bitmap data in the peer->context structure instead, so that
> it can be reused for every frame, and freed at destruction.
> ---
>  libweston/compositor-rdp.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
> index 091472b0..7b1ab06d 100644
> --- a/libweston/compositor-rdp.c
> +++ b/libweston/compositor-rdp.c
> @@ -142,6 +142,7 @@ struct rdp_peer_context {
>   wStream *encode_stream;
>   RFX_RECT *rfx_rects;
>   NSC_CONTEXT *nsc_context;
> + BYTE * bitmapData;
>  
>   struct rdp_peers_item item;
>  };
> @@ -312,7 +313,10 @@ rdp_peer_refresh_raw(pixman_region32_t *region, 
> pixman_image_t *image, freerdp_p
>  cmd->destTop = top;
>  cmd->destBottom = top + cmd->height;
>  cmd->bitmapDataLength = cmd->width * cmd->height * 4;
> -cmd->bitmapData = (BYTE *)realloc(cmd->bitmapData, 
> cmd->bitmapDataLength);
> +
> +RdpPeerContext *context = (RdpPeerContext 
> *)peer->context;
> +context->bitmapData = (BYTE 
> *)realloc(context->bitmapData, cmd->bitmapDataLength);
> +cmd->bitmapData = context->bitmapData;
>  
>  subrect.y1 = top;
>  subrect.y2 = top + cmd->height;
> @@ -659,6 +663,7 @@ int rdp_implant_listener(struct rdp_backend *b, 
> freerdp_listener* instance)
>  static FREERDP_CB_RET_TYPE
>  rdp_peer_context_new(freerdp_peer* client, RdpPeerContext* context)
>  {
> + context->bitmapData = NULL;
>   context->item.peer = client;
>   context->item.flags = RDP_PEER_OUTPUT_ENABLED;
>  
> @@ -715,6 +720,8 @@ rdp_peer_context_free(freerdp_peer* client, 
> RdpPeerContext* context)
>* but it would crash on reconnect */
>   }
>  
> + free(context->bitmapData);
> +
>   Stream_Free(context->encode_stream, TRUE);
>   nsc_context_free(context->nsc_context);
>   rfx_context_free(context->rfx_context);
> 

Reviewed-by: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel