- 28 Jul, 2014 4 commits
-
-
Roger Quadros authored
Update the bindings for touchscreen size. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Roger Quadros authored
Provide device tree support and binding information. Also provide support for a new chip "pixcir_tangoc". Signed-off-by:
-
Roger Quadros authored
Some variants of the Pixcir touch controller support up to 5 simultaneous fingers and hardware tracking IDs. Prepare the driver for that. Signed-off-by:
-
Roger Quadros authored
Switch to using the Type-B Multi-Touch protocol. Reviewed-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
- 26 Jul, 2014 16 commits
-
-
Yunkang Tang authored
Such as found on the new Toshiba Portégé Z30-A and Z40-A. Signed-off-by:
Yunkang Tang <yunkang.tang@cn.alps.com> [hdegoede@redhat.com: Remove softbutton handling, this is done in userspace] [hdegoede@redhat.com: Report INPUT_PROP_BUTTONPAD] [hdegoede@redhat.com: Do not report fake PRESSURE, reporting BTN_TOUCH is enough] [hdegoede@redhat.com: Various cleanups / refactoring] Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
So that decode functions can return a failure when appropriate. Signed-off-by:
-
Hans de Goede authored
If we detect more then 2 fingers report 2 touches, rather then only reporting the upper left corner of the bounding box. Signed-off-by:
-
Hans de Goede authored
Move all the semi-mt specific handling shared between the v3 and v4 handling code to a common helper function. Signed-off-by:
-
Hans de Goede authored
For v3 protocol devices, use the more accurate single touch data when the mt data contains only one finger. Note the mt data reporting a finger count of 1 should never happen, but better safe then sorry. This brings the v3 bitmap handling in line with what the v4 code does, allowing to factor out the common bits into a helper function. Signed-off-by:
-
Hans de Goede authored
When there are 2 fingers on the pad we don't know which one is which, so use input_mt_assign_slots to make sure the right set of coordinates ends up in the right slot. Besides ensuring things end up in the right slot, this also results in a nice cleanup, since sync_frame also handles non mt position and btn_touch reporting. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for switching the DIY mt handling to using input_mt_assign_slots && input_mt_sync_frame. struct alps_fields is quite large, so while making changes to almost all uses of it lets put it in our priv data instead of on the stack. Having it in our priv data also allows using it directly for storing values which need to be cached, rather then having separate x, y, z, fingers, etc. copies in our priv data. Signed-off-by:
-
Hans de Goede authored
This fixes 2 fingers at the same height or width on the touchpad getting reported at different y / x coordinates. Note num_bits is always at least 1. Signed-off-by:
-
Hans de Goede authored
alps_process_bitmap was resetting the point bit-count as soon as it saw 2 0 bits in a row. This means that unless the high point actually is at the end of the bitmap, it would always get its num_bits set to 0. Instead reset num_bits to 0 on a 0->1 transition, so that with > 2 fingers we only count the number of bits occupied by the highest finger. Signed-off-by:
-
Hans de Goede authored
Factor out the identical code for getting the bitmap points for x and y into a helper function. Signed-off-by:
-
Hans de Goede authored
Rushmore models don't have the Y-axis data in the bitmap inverted. Since we now have 2 different Y orientations, make the Y bitmap data processing use a forward loop like the X bitmap data processing, unifying the 2, and invert the data later, except on Rushmore. So far no-one has noticed this because the synaptics driver only uses the non mt coordinates (except on clickpads, and there are no alps clickpads using process_bitmap). Signed-off-by:
-
Hans de Goede authored
V3 models only report mt bitmap data when there are 2 or more fingers on the touchpad. So always generate 2 positions in alps_process_bitmap, and for v3 models only fall back to st data when there was no mt data in a mt packet (which should never happen). This fixes 2 finger scrolling not working when using 2 fingers close to each other. Signed-off-by:
-
Yunkang Tang authored
Signed-off-by:
-
Pramod Gurav authored
Signed-off-by:
Pramod Gurav <pramod.gurav@smartplayin.com> Signed-off-by:
-
Dmitry Torokhov authored
wacom_wac.h will be moving to drivers/hid. Since we only need 3 definitions from it let's simply copy them over. Acked-by:
-
- 24 Jul, 2014 3 commits
-
-
Dmitry Torokhov authored
Wire up open/close so we do not try to send events until someone uses them; this also allows us to remove micro_ts_remove() and rely fully on managed resources. Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dmitry Artamonow authored
This adds a driver for the touchscreen connected to the Atmel microcontroller on the iPAQ h3xxx series. Based on a driver from handhelds.org 2.6.21 kernel, written by Alessandro GARDICH, with the bulk of the code for the new input architecture rewritten by Dmitry Atamonow, and the final polish by Linus Walleij. Signed-off-by:
Alessandro GARDICH <gremlin@gremlin.it> Signed-off-by:
Dmitry Artamonow <mad_soft@inbox.ru> Signed-off-by:
-
Dmitry Torokhov authored
Merge with mainline to bring in changes to MFD to allow merging ipaq-micro-ts driver.
-
- 23 Jul, 2014 14 commits
-
-
Nick Dyer authored
maXTouch chips allow the reading of multiple messages in a single I2C transaction, which reduces bus overhead and improves performance/latency. The number of messages available to be read is given by the value in the T44 object which is located directly before the T5 object. Signed-off-by:
Nick Dyer <nick.dyer@itdev.co.uk> Acked-by:
Benson Leung <bleung@chromium.org> Acked-by:
Yufeng Shen <miletus@chromium.org> Signed-off-by:
-
Nick Dyer authored
This is in preparation for support of the T44 message count object. Also, cache T5 address to avoid lookup on every interrupt cycle. Signed-off-by:
-
Nick Dyer authored
By storing the previous T6 status byte multiple debug output of the same status can be suppressed (for example CFGERR). Signed-off-by:
-
Nick Dyer authored
The T5 object may have various sizes depending on the objects used on the particular maXTouch chip and firmware version, therefore it can't be hardcoded in the driver. Allocate a buffer on probe instead. Signed-off-by:
-
Nick Dyer authored
The MXT device may be in bootloader mode on probe, due to: 1) APP CRC failure, either: a) flash corruption b) bad power or other intermittent problem while checking CRC 2) If the device has been reset 10 or more times without accessing comms 3) Warm probe, device was in bootloader mode already This code attempts to recover from 1(b) and 3. There is an additional complexity: we have to try two possible bootloader addresses because the mapping is not one-to-one and we don't know the exact model yet. Signed-off-by:
-
Nick Dyer authored
Later chips (for example mXT1664S) different mappings for bootloader addresses. This means that we must look at the family ID to determine which address to use. Signed-off-by:
-
Nick Dyer authored
On a warm probe, the device might be in a state where an flash operation was not completed. Signed-off-by:
-
Nick Dyer authored
If the bootloader on the touchscreen controller fails to initialise the firmware image, it stays in bootloader mode and reports a failure. It is possible to reflash a working firmware image from this state. Signed-off-by:
-
Nick Dyer authored
By validating the checksum, we can identify if the configuration is corrupt. In addition, this patch writes the configuration in a short series of block writes rather than as many individual values. Signed-off-by:
-
Nick Dyer authored
The existing implementation which encodes the configuration as a binary blob in platform data is unsatisfactory since it requires a kernel recompile for the configuration to be changed, and it doesn't deal well with firmware changes that move values around on the chip. Atmel define an ASCII format for the configuration which can be exported from their tools. This patch implements a parser for that format which loads the configuration via the firmware loader and sends it to the MXT chip. Signed-off-by:
-
Stephen Warren authored
Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Benson Leung authored
Touchpads are pointers, so make sure to pass the correct values to input_mt_report_pointer_emulation(). Without this, tap-to-click doesn't work. Signed-off-by:
-
Nick Dyer authored
It is useful to initialise the input device later: - Screen parameters may not be not known yet, for instance if waiting for firmware loader to return. - Device may be in bootloader mode on probe (but could still be recovered by firmware download). In addition, later devices have a different touchscreen object (T100) which requires handling differently. This also reduces the complexity of the probe function. Signed-off-by:
-
Nick Dyer authored
The maXTouch chips use the CHG line to generate status events in bootloader mode, and during configuration download, before there is enough information to configure the input device. Therefore set up the interrupt handler earlier. However, this introduces states where parts of the interrupt processing must not run. Use data->object_table as a way to tell whether the chip information is valid, and data->input_dev as a way to tell whether it is valid to generate input report. Signed-off-by:
-
- 21 Jul, 2014 3 commits
-
-
David Herrmann authored
This ioctl is the counterpart to EVIOCGVERSION and returns the uinput-version the kernel was compiled with. Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
David Herrmann authored
This moves basic checks and setup from uinput_setup_device() into uinput_validate_absbits() to make it easier to use. This way, we can call it from other places without copying the boilerplate code. Reviewed-by:
-
Heiko Stuebner authored
It's possible that the controller has an individually switchable power supply. Therefore add support to control a supplying regulator. As this is not always the case, the regulator is requested as optional. Signed-off-by:
Heiko Stuebner <heiko.stuebner@bq.com> Signed-off-by:
-
