focaltech_finger_state stores finger coordinates x and y as unsigned
int. When processing relative packets, negative deltas can cause
unsigned integer underflow if the finger moves past the left or bottom
boundary of the touchpad, wrapping the coordinates to values near
UINT_MAX.
When clamping the coordinates in focaltech_report_state(), these
underflowed values are clamped against priv->x_max / priv->y_max instead
of 0, causing the cursor to jump erratically to the opposite edge of the
touchpad.
Change the coordinate variables and limits to signed int so that
negative values resulting from relative movements clamp correctly to 0,
and write the clamped values back to state in focaltech_report_state()
to prevent coordinate wind-up accumulation at the touchpad boundaries.
Fixes: 05be1d079e ("Input: psmouse - support for the FocalTech PS/2 protocol extensions")
Reported-by: [email protected]
Link: https://patch.msgid.link/[email protected]
Assisted-by: Antigravity:gemini-3.6-flash
Signed-off-by: Dmitry Torokhov <[email protected]>
Make finger2 (and also finger1) unsigned, so that if the finger index in
the packet is 0 then subtracting 1 creates an array index which overflows
above the existing check for FOC_MAX_FINGERS, as the existing comment says
it should, instead of writing to state->fingers[-1].
Fixes: 05be1d079e ("Input: psmouse - support for the FocalTech PS/2 protocol extensions")
Signed-off-by: Richard Davies <[email protected]>
Link: https://patch.msgid.link/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <[email protected]>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <[email protected]>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
psmouse->name "Focaltech Touchpad" is an overkill. In xinput it is too long
as "FocaltechPS/2 Focaltech Focaltech Touchpad"
In focaltech_report_state() pointer to psmouse->dev is already stored as
*dev
Signed-off-by: Dmitry Tunin <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
We get 1 warning when building kernel with W=1:
drivers/input/mouse/focaltech.c:393:6: warning: no previous prototype for 'focaltech_set_resolution' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
The fact that we were calling focaltech_init() even when Focaltech support
is disabled was confusing. Rearrange the code so that if support is
disabled we continue to fall through the rest of protocol probing code
until we get to full reset that Focaltech devices need to work properly.
Also, replace focaltech_init() with a stub now that it is only called when
protocol is enabled.
Reviewed-by: Hans de Goede <[email protected]>
Reviewed-by: Pali Rohár <[email protected]>
Tested-by: Marcin Sochacki <[email protected]>
Tested-by: Till <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
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: Dmitry Tunin <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Apparently, the threshold for large contact area seems to be rather low on
some devices, causing the touchpad to frequently freeze during normal
usage. Because we do now know how we are supposed to use the value in
question, this commit just drops the related code completely.
Signed-off-by: Mathias Gottschlag <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
These PS/2 commands make some touchpads stop responding, so this commit
adds some dummy functions to replace the generic implementation. Because
scale changes were not encapsulated in a method of struct psmouse yet, this
commit adds a method set_scale to psmouse.
Signed-off-by: Mathias Gottschlag <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
We don't know whether x_max or y_max really hold the maximum possible
coordinates, and we don't know for sure whether we correctly interpret the
coordinates sent by the touchpad, so we clamp the reported values to
prevent confusion in userspace code.
Signed-off-by: Mathias Gottschlag <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
The size has in most cases already been fetched from the touchpad, the
hardcoded values should have been removed.
Signed-off-by: Mathias Gottschlag <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Instead of having various protocols provide <protocol>_supported()
functions, let's use IS_ENABLED() macro that works well in "if" statements.
Acked-by: Hans de Goede <[email protected]>
Reviewed-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Most of the protocol for these touchpads has been reverse engineered. This
commit adds a basic multitouch-capable driver.
A lot of the protocol is still unknown. Especially, we don't know how to
identify the device yet apart from the PNP ID.
The previous workaround for these devices has been left in place in case
the driver is not compiled into the kernel or in case some other device
with the same PNP ID is not recognized by the driver yet still has the same
problems with the device probing code.
Signed-off-by: Mathias Gottschlag <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
The Asus X450 and X550 laptops use a PS/2 touchpad from a new
manufacturer called FocalTech:
https://bugzilla.kernel.org/show_bug.cgi?id=77391https://bugzilla.redhat.com/show_bug.cgi?id=1110011
The protocol for these devices is not known at this time, but even
without knowing the protocol they need some special handling. They get
upset by some of our other PS/2 device probing, and once upset generate
random mouse events making things unusable even with an external mouse.
This patch adds detection of these devices based on their pnp ids, and
when they are detected, treats them as a bare ps/2 mouse. Doing things
this way they at least work in their ps/2 mouse emulation mode.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Dmitry Torokhov