On Fri, Nov 13, 2020 at 08:42:37AM +0100, Benjamin Tissoires wrote:
On Fri, Nov 13, 2020 at 8:40 AM Dmitry Torokhov
[off-list ref] wrote:
quoted
On Thu, Nov 12, 2020 at 11:01:57AM +0000, Lee Jones wrote:
quoted
Fixes the following W=1 kernel build warning(s):
drivers/input/touchscreen/surface3_spi.c: In function ‘surface3_spi_process_touch’:
drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable ‘timestamp’ set but not used [-Wunused-but-set-variable]
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Benjamin Tissoires <redacted>
Cc: <redacted>
Signed-off-by: Lee Jones <redacted>
---
drivers/input/touchscreen/surface3_spi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/input/touchscreen/surface3_spi.c b/drivers/input/touchscreen/surface3_spi.c
index ce4828b1415a8..72dc4c562a4e1 100644
--- a/drivers/input/touchscreen/surface3_spi.c
+++ b/drivers/input/touchscreen/surface3_spi.c
@@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct surface3_ts_data *ts_data,
static void surface3_spi_process_touch(struct surface3_ts_data *ts_data, u8 *data)
{
- u16 timestamp;
unsigned int i;
- timestamp = get_unaligned_le16(&data[15]);
Benjamin, should we pass timing data on to userspace instead?
Last time I checked, libinput was not using the HW timestamp. So I
don't mind dropping it.
I'm assuming this would be passed on as MSC_TIMESTAMP?
I never found the time implementing this and I mask MSC_TIMESTAMP on most
devices anyway (except for Dell's i2c touchpads where I need it to work
around a fw bug). so at least from libinput's POV it wouldn't have any
effect either way.
Cheers,
Peter
Not sure if chrome/android uses it.
Cheers,
Benjamin
quoted
quoted
for (i = 0; i < 13; i++) {
struct surface3_ts_data_finger *finger;
--
2.25.1
Thanks.
--
Dmitry