- 07 Apr, 2020 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 5.7 merge window.
-
- 01 Apr, 2020 3 commits
-
-
Rajat Jain authored
Replace the /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ with /* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */ to help coreboot community consume this file without relaxing their licensing checks. Signed-off-by:
Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20200329172513.133548-1-rajatja@google.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
The Acer Aspire 5738z has a button to disable (and re-enable) the touchpad next to the touchpad. When this button is pressed a LED underneath indicates that the touchpad is disabled (and an event is send to userspace and GNOME shows its touchpad enabled / disable OSD thingie). So far so good, but after re-enabling the touchpad it no longer works. The laptop does not have an external ps2 port, so mux mode is not needed and disabling mux mode fixes the touchpad no longer working after toggling it off and back on again, so lets add this laptop model to the nomux list. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200331123947.318908-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
acpi_evaluate_object() and acpi_execute_simple_method() are not part of the group of ACPI related functions which get stubbed by include/linux/acpi.h when ACPI support is disabled, so the IRQ_PIN_ACCESS_ACPI_METHOD handling code must be stubbed out. For consistency use the same #if condition as which is used to replace goodix_add_acpi_gpio_mappings with a stub. Fixes: c5fca485 ("Input: goodix - add support for controlling the IRQ pin through ACPI methods") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Bastien Nocera <hadess@hadess.net> Signed-off-by:
-
- 27 Mar, 2020 1 commit
-
-
Dmitry Torokhov authored
We need to refresh timestamp when emitting key autorepeat events, otherwise they will carry timestamp of the original key press event. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206929 Fixes: 3b51c44b ("Input: allow drivers specify timestamp for input events") Cc: stable@vger.kernel.org Reported-by:
teika kazura <teika@gmx.com> Tested-by:
-
- 26 Mar, 2020 1 commit
-
-
Dmitry Torokhov authored
We should try to keep keycodes sequential unless there is a reason to leave a gap in numbering, so let's move it from 0x280 to 0x27a while we still can. Fixes: 3b059da9 ("Input: allocate keycode for Selective Screenshot key") Acked-by:
-
- 24 Mar, 2020 24 commits
-
-
Benjamin Gaignard authored
Convert the EDT-FT5x06 to DT schema using json-schema. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200207084657.31195-1-benjamin.gaignard@st.comSigned-off-by:
-
Eugene Syromiatnikov authored
The commit 19ba1eb1 ("Input: psmouse - add a custom serio protocol to send extra information") introduced usage of the BIT() macro for SERIO_* flags; this macro is not provided in UAPI headers. Replace if with similarly defined _BITUL() macro defined in <linux/const.h>. Fixes: 19ba1eb1 ("Input: psmouse - add a custom serio protocol to send extra information") Signed-off-by:
Eugene Syromiatnikov <esyr@redhat.com> Cc: <stable@vger.kernel.org> # v5.0+ Link: https://lore.kernel.org/r/20200324041341.GA32335@asgard.redhat.comSigned-off-by:
-
Andrew Duggan authored
The previous patch "c5ccf2ad (Input: synaptics-rmi4 - switch to reduced reporting mode)" enabled reduced reporting mode unintentionally on some devices, if the firmware was configured with default Delta X/Y threshold values. The result unintentionally degrade the performance of some touchpads. This patch checks to see that the driver is modifying the delta X/Y thresholds before modifying the reporting mode. Signed-off-by:
Andrew Duggan <aduggan@synaptics.com> Fixes: c5ccf2ad ("Input: synaptics-rmi4 - switch to reduced reporting mode") Link: https://lore.kernel.org/r/20200312005549.29922-1-aduggan@synaptics.comSigned-off-by:
-
Yussuf Khalil authored
This laptop (and perhaps other variants of the same model) reports an SMBus-capable Synaptics touchpad. Everything (including suspend and resume) works fine when RMI is enabled via the kernel command line, so let's add it to the whitelist. Signed-off-by:
Yussuf Khalil <dev@pp3345.net> Link: https://lore.kernel.org/r/20200307213508.267187-1-dev@pp3345.net Cc: stable@vger.kernel.org Signed-off-by:
-
Andy Shevchenko authored
The 'axis + 1' calculation is implicit and potentially error prone. Moreover, few lines before the axis is set explicitly for both X and Y. Do the same when retrieving different properties for X and Y. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200303180917.12563-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Yannick Fertre authored
Add support for it by adding compatible and supported chip data (default settings used). The chip data on GT9147 is similar to GT912, like - config data register has 0x8047 address - config data register max len is 240 - config data checksum has 8-bit Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Reviewed-by:
-
Yannick Fertre authored
Add support for it by adding compatible. The chip data on GT9147 is similar to GT912, like - config data register has 0x8047 address - config data register max len is 240 - config data checksum has 8-bit Signed-off-by:
-
Icenowy Zheng authored
Goodix GT917S is a touchscreen chip from Goodix that is in the GT1x family. Add its support by assigning the gt1x config to it. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Reviewed-by:
-
Icenowy Zheng authored
For Goodix GT917S chip, the chip ID string is "917S", which contains not only numbers now. Use string-based chip ID in the driver to support this chip and further chips with alphanumber ID. Signed-off-by:
-
Icenowy Zheng authored
Goodix GT917S is a new touchscreen chip from Goodix. Add its compatible string to the device tree binding. Signed-off-by:
-
Dmitry Mastykin authored
Some devices with a goodix touchscreen have more then 1 capacitive touch-key. This commit replaces the current support for a single touch-key, which ignored the reported key-code. With support for up to 7 touch-keys, based upon checking the key-code which is post-fixed to any reported touch-data. KEY_LEFTMETA is assigned to the first touch-key (it will still be the default keycode for devices with a single touch-key). KEY_F1, KEY_F2... are assigned as default keycode for the other touch-keys. This commit also add supports for keycode remapping, so that systemd-udev's hwdb can be used to remap the codes to send keycodes to match the icons on the buttons for devices with more then 1 touch-key. Signed-off-by:
Dmitry Mastykin <dmastykin@astralinux.ru> Reviewed-by:
-
Dmitry Mastykin authored
The goodix panel sends spurious interrupts after a 'finger up' event, which always cause a timeout. We were exiting the interrupt handler by reporting touch_num == 0, but this was still processed as valid and caused the code to use the uninitialised point_data, creating spurious key release events. Report an error from the interrupt handler so as to avoid processing invalid point_data further. Signed-off-by:
-
Hans de Goede authored
On some ACPI/x86 devices (where we use one of the ACPI IRQ pin access methods) the firmware is buggy, it does not properly reset the controller at boot, and we cannot communicate with it. Normally on ACPI/x86 devices we do not want to reset the controller at probe time since in some cases this causes the controller to loose its configuration and this is loaded into it by the system's firmware. So on these systems we leave the reset_controller_at_probe flag unset, even though we have a access to both the IRQ and reset pins and thus could reset it. In the case of the buggy firmware we have to reset the controller to actually be able to talk to it. This commit adds a special case for this, if the goodix_i2c_test() fails, and we have not reset the controller yet; and we do have a way to reset the controller then retry the i2c-test after resetting the controller. This fixes the driver failing at probe on ACPI/x86 systems with this firmware bug. Reported-and-tested-by:
-
Hans de Goede authored
Some devices, e.g the Trekstor Primetab S11B, lose there config over a suspend/resume cycle (likely the controller loses power during suspend). This commit reads back the config version on resume and if matches the expected config version it resets the controller and resends the config we read back and saved at probe time. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Make goodix_send_cfg() take a raw buffer as argument instead of a struct firmware *cfg, so that it can also be used to restore the config on resume if necessary. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Our goodix_check_cfg_* helpers do things like: int i, raw_cfg_len = cfg->size - 2; ... if (check_sum != cfg->data[raw_cfg_len]) { When cfg->size < 2, this will end up indexing the cfg->data array with a negative value, which will not end well. To fix this this commit adds a new GOODIX_CONFIG_MIN_LENGTH define and adds a minimum size check for firmware-config files using this new define. For consistency this commit also adds a new GOODIX_CONFIG_GT9X_LENGTH for the length used for recent gt9xx and gt1xxx chips, instead of using GOODIX_CONFIG_MAX_LENGTH for this, so that if other length defines get added in the future it will be clear that the MIN and MAX defines should contain the min and max values of all the other defines. Signed-off-by: -
Hans de Goede authored
Save a copy of the config in goodix_read_config(), this is a preparation patch for restoring the config if it was lost after a supend/resume cycle. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Move the defines to above the struct goodix_ts_data declaration, so that the MAX defines can be used inside the struct goodix_ts_data declaration. No functional changes, just moving a block of code. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Some Apollo Lake (x86, UEFI + ACPI) devices only list the reset GPIO in their _CRS table and the bit-banging of the IRQ line necessary to wake-up the controller from suspend can be done by calling 2 Goodix custom / specific ACPI methods. This commit adds support for controlling the IRQ line in this matter, allowing us to properly suspend the touchscreen controller on such devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
On most Bay Trail (x86, UEFI + ACPI) devices the ACPI tables do not have a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding "irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name without first manually adding mappings ourselves. These devices contain 2 GpioIo resource in their _CRS table, on all 4 such devices which I have access to, the order of the 2 GPIOs is reset, int. Note that the GPIO to which the touchscreen controller irq pin is connected is configured in direct-irq mode on these Bay Trail devices, the pinctrl-baytrail.c driver still allows controlling the pin as a GPIO in this case, but this is not necessarily the case on other X86 ACPI platforms, nor do we have a guarantee that the GPIO order is the same elsewhere, so we limit the use of a _CRS table with 2 GpioIo resources to Bay Trail devices only. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
On most Cherry Trail (x86, UEFI + ACPI) devices the ACPI tables do not have a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding "irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name without first manually adding mappings ourselves. These devices contain 1 GpioInt and 1 GpioIo resource in their _CRS table: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.PCI0.I2C2", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0013 } GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0019 } }) Return (RBUF) /* \_SB_.PCI0.I2C2.TCS1._CRS.RBUF */ } There is no fixed order for these 2. This commit adds code to check that there is 1 of each as expected and then registers a mapping matching their order using devm_acpi_dev_add_driver_gpios(). This gives us access to both GPIOs allowing us to properly suspend the controller during suspend, and making it possible to reset the controller if necessary. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Signed-off-by: -
Hans de Goede authored
Before this commit we would always reset the controller at probe when we have access to the GPIOs which are necessary to do a reset. Doing the reset requires access to the GPIOs, but just because we have access to the GPIOs does not mean that we should always reset the controller at probe. On X86 ACPI platforms the BIOS / UEFI firmware will already have reset the controller and it will have loaded the device specific config into the controller. Doing the reset sometimes causes the controller to lose its configuration, so on X86 ACPI platforms this is not a good idea. This commit adds a new reset_controller_at_probe boolean to control the reset at probe behavior. This commits sets the new bool to true when we set irq_pin_access_method to IRQ_PIN_ACCESS_GPIO, so there are no functional changes. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
At least on X86 ACPI platforms it is not necessary to load the touchscreen controller config from disk, if it needs to be loaded this has already been done by the BIOS / UEFI firmware. Even on other (e.g. devicetree) platforms the config-loading as currently done has the issue that the loaded cfg file is based on the controller model, but the actual cfg is device specific, so the cfg files are not part of linux-firmware and this can only work with a device specific OS image which includes the cfg file. And we do not need access to the GPIOs at all to load the config, if we do not have access we can still load the config. So all in all tying the decision to try to load the config from disk to being able to access the GPIOs is not desirable. This commit adds a new load_cfg_from_disk boolean to control the firmware loading instead. This commits sets the new bool to true when we set irq_pin_access_method to IRQ_PIN_ACCESS_GPIO, so there are no functional changes. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Suspending Goodix touchscreens requires changing the interrupt pin to output before sending them a power-down command. Followed by wiggling the interrupt pin to wake the device up, after which it is put back in input mode. So far we have only effectively supported this on devices which use devicetree. On X86 ACPI platforms both looking up the pins; and using a pin as both IRQ and GPIO is a bit more complicated. E.g. on some devices we cannot directly access the IRQ pin as GPIO and we need to call ACPI methods to control it instead. This commit adds a new irq_pin_access_method field to the goodix_chip_data struct and adds goodix_irq_direction_output and goodix_irq_direction_input helpers which together abstract the GPIO accesses to the IRQ pin. This is a preparation patch for adding support for properly suspending the touchscreen on X86 ACPI platforms. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Signed-off-by:
-
- 18 Mar, 2020 1 commit
-
-
Rajat Jain authored
New Chrome OS keyboards have a "snip" key that is basically a selective screenshot (allows a user to select an area of screen to be copied). Allocate a keycode for it. Signed-off-by:
Harry Cutts <hcutts@chromium.org> Link: https://lore.kernel.org/r/20200313180333.75011-1-rajatja@google.comSigned-off-by:
-
- 06 Mar, 2020 6 commits
-
-
Nick Reitemeyer authored
The Coreriver TouchCore 360 is like the midas board touchkey, but it is using a fixed regulator. Signed-off-by:
Nick Reitemeyer <nick.reitemeyer@web.de> Link: https://lore.kernel.org/r/20200121141525.3404-3-nick.reitemeyer@web.deSigned-off-by:
-
Nick Reitemeyer authored
Signed-off-by:
-
Nick Reitemeyer authored
Coreriver is a South Korean microcontroller manufacturer: http://coreriver.comSigned-off-by:
-
Dan Carpenter authored
These functions are supposed to return negative error codes but instead it returns true on failure and false on success. The error codes are eventually propagated back to user space. Fixes: 48a2b783 ("Input: add Raydium I2C touchscreen driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200303101306.4potflz7na2nn3od@kili.mountain Cc: stable@vger.kernel.org Signed-off-by:
-
Johnny Chuang authored
This patch supports reporting resolution for ABS_MT_TOUCH_MAJOR event. This information is needed in showing pressure/width radius. Signed-off-by:
Johnny Chuang <johnny.chuang@emc.com.tw> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/1582766000-23023-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by:
-
Sergei A. Trusov authored
The touchscreen on the Cube I15-TC don't match the default display, with 0,0 touches being reported when touching at the top-right of the screen. Add a quirk to invert the x coordinate. Reported-and-tested-by:
Arkadiy <arkan49@yandex.ru> Signed-off-by:
Sergei A. Trusov <sergei.a.trusov@ya.ru> Reviewed-by:
-
- 15 Feb, 2020 3 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200214172132.GA28389@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
