Skip to content
GitLab
  1. Jun 10, 2015
  3. Jun 09, 2015
  5. Jun 03, 2015
    • Dmitry Tunin's avatar
      Input: focaltech - report finger width to userspace · 85919a00
      Dmitry Tunin authored 
      

Focaltech touchpads report finger width in packet[5] of absolute packet.
Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
0xff is reported, when a large contact area is detected.
This can be handled in userspace.

Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      85919a00
    • Arnd Bergmann's avatar
      tty: remove platform_sysrq_reset_seq · ffb6e0c9
      Arnd Bergmann authored 
      The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.

Fixes: 154b7a48

 ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      ffb6e0c9
  7. May 27, 2015
  9. May 23, 2015
  11. May 22, 2015
  13. May 21, 2015
  15. May 16, 2015
  17. May 14, 2015
  19. May 09, 2015
  21. May 08, 2015
    • Marek Vasut's avatar
      Input: smtpe-ts - wait 50mS until polling for pen-up · 9ceeb59c
      Marek Vasut authored 
      

Wait a little bit longer, 50mS instead of 20mS, until the driver starts
polling for pen-up. The problematic behavior before this patch is applied
is as follows. The behavior was observed on the STMPE610QTR controller.

Upon a physical pen-down event, the touchscreen reports one set of x-y-p
coordinates and a pen-down event. After that, the pen-up polling is
triggered and since the controller is not ready yet, the polling mistakenly
detects a pen-up event while the physical state is still such that the pen
is down on the touch surface.

The pen-up handling flushes the controller FIFO, so after that, all the
samples in the controller are discarded. The controller becomes ready
shortly after this bogus pen-up handling and does generate again a pen-down
interrupt. This time, the controller contains x-y-p samples which all read
as zero. Since pressure value is zero, this set of samples is effectively
ignored by userland.

In the end, the driver just bounces between pen-down and bogus pen-up
handling, generating no useful results. Fix this by giving the controller a
bit more time before polling it for pen-up.

Signed-off-by: default avatarMarek Vasut <marex@denx.de>
Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      9ceeb59c