- 13 4月, 2015 1 次提交
-
-
由 Hans de Goede 提交于
When the left touchpad button gets pressed, and then the trackpoint is moved, and then the button is released, the following happens: 1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1 2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in this packet because when the trackstick is active it communicates the combined touchpad + pointing stick buttons in the trackstick packet, since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter to alps_report_buttons the combining is not detected and the pointing stick evdev node will also report BTN_LEFT 1 3) on release of the button a pointing stick packet with BTN_LEFT 0 is received and the pointing stick evdev node will report BTN_LEFT 0 Note how because of the passing as NULL for dev2 the touchpad evdev node will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button. This is a regression in 4.0 introduced by commit 04aae283 ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") This commit fixes this by passing in the touchpad evdev as dev2 parameter when calling alps_report_buttons for the pointingstick on alps v2 devices, so that alps_report_buttons correctly detect that we're already reporting the button as pressed via the touchpad evdev node, and will also send the release event there. Cc: stable@vger.kernel.org # 4.0 Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 06 4月, 2015 2 次提交
-
-
由 Hans de Goede 提交于
On V2 devices the DualPoint Stick reports bare packets, these should be reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also has the INPUT_PROP_POINTING_STICK propbit set. Note that since there is no way to distinguish these packets from an external PS/2 mouse (insofar as these laptops have an external PS/2 port) this means that we will be reporting PS/2 mouse events via this evdev node too, as we've been doing in kernel 3.19 and older. This has been tested on a Dell Latitude D620 and a Dell Latitude E6400, which both have a V2 touchpad + a DualPoint Stick which reports bare packets. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Bare packets should be reported via the same evdev device independent on whether they are detected on the beginning of a packet or in the middle of a packet. This has been tested on a Dell Latitude E6400, where the DualPoint Stick reports bare packets, which get reported via dev3 when the touchpad is idle, and via dev2 when the touchpad and stick are used simultaneously. This commit fixes this inconsistency by always reporting bare packets via dev3. Note that since the come from a DualPoint Stick they really should be reported via dev2, this gets fixed in a later commit. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 24 3月, 2015 1 次提交
-
-
由 Dmitry Torokhov 提交于
Commit 3296f71c ("Input: ALPS - consolidate setting protocol parameters") inadvertently moved call to alps_dolphin_get_device_area() from v5 to v7 protocol, causing both protocols report incorrect maximum values for X and Y axes which resulted in crash in Synaptics X driver. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94801Reported-by: NSantiago Gala <sgala@apache.org> Reported-by: NPali Rohár <pali.rohar@gmail.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 05 3月, 2015 1 次提交
-
-
由 Dmitry Torokhov 提交于
This fixes memory leak introduced by commit a09221e8Acked-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 16 2月, 2015 8 次提交
-
-
由 Pali Rohár 提交于
This patch move all packet info from driver source code to documentation and adds info about v6 packet format (from driver source code). Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
The comment about suspicions entry 0x20, 0x02, 0x0e has over time drifted away and it become hard to figure out what it meant. Let's move it back so it is clear. Reported-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pali Rohár 提交于
Previously dev2 device was used for both external PS/2 mouse and internal trackstick device (if available). This change introduces dev3 device which is used for external PS/2 mouse data and dev2 is now used only for trackstick. In case that trackstick is not present dev2 is not created, so userspace does not see non existent device in system. Because laptops with ALPS devices often do not use i8042 active multiplexing all data (from touchpad, trackstick and external PS/2 mouse) come to one port. So it is not possible to know if external PS/2 mouse is connected or not. In most cases external PS/2 mouse is not connected so driver will create dev3 input device after first bare PS/2 packet will be received. So there will not be "ghost" input device. This change also helps in identifying possible problems in future if driver decides to report 6-bytes trackstick packets as 3-bytes bare PS/2 (data will be reported to dev3 instead dev2). Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
On some Dell Latitudes we fail to identify presence of trackstick unless we reset the device. The issue is quite benign as we do perform reset in alps_init(), so the trackstick ends up working, but mouse name reported to userspace is not accurate. In order to fix the issue while avoiding the additional lengthy reset we move the resrt to alps_detect() and keep the discovered state to be used later in alps_init(). Reported-by: NPali Rohár <pali.rohar@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
Move setting of all protocol properties into alps_set_protocol (former alps_set_defaults) instead of having it split between several functions. Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
In preparation of reworking the way we set protocol parameters let's split certain protocol items from alps_model_info into a separate structure. Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
Even though Rushmore is very close to V3 protocol it is sufficiently different to warrant it's own protocol name. Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
In order to accommodate new protocol number for Rushmore touchpads let's shift protocol numbers by 8 bits (i.e. 1 -> 0x100) - this way we keep protocol version reported in input device id the same as it was, but add some holes in numbering. Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 02 2月, 2015 1 次提交
-
-
由 Henrik Rydberg 提交于
Some devices are not fast enough to differentiate between a fast-moving contact and a new contact. This problem cannot be fully resolved because information is truly missing, but it is possible to safe-guard against obvious mistakes by restricting movement with a maximum displacement. The new problem formulation for dmax > 0 cannot benefit from the speedup for positive definite matrices, but since the convergence is faster, the result is about the same. For a handful of contacts, the latency difference is truly negligible. Suggested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NHenrik Rydberg <rydberg@bitmath.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 12 1月, 2015 2 次提交
-
-
由 Pali Rohár 提交于
Make sure that driver does not process bogus packets as trackstick data when there is no trackstick present and emit warnings in dmesg so potential issues with trackstick handling will be visible for debugging. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pali Rohár 提交于
This change fixes name, product and version of dev2 input device based on format used in function psmouse_switch_protocol() in file psmouse-base.c. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 19 12月, 2014 4 次提交
-
-
由 Hans de Goede 提交于
Add a table documenting where all the bits are in the v7 touchpad packets. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Protocol v7 uses the middle / right button bits on clickpads to communicate "location" information of a 3th touch (and possible 4th) touch on clickpads. Specifically when 3 touches are down, if one of the 3 touches is in the left / right button area, this will get reported in the middle / right button bits and the touchpad will still send a TWO type packet rather then a MULTI type packet, so when this happens we must add the finger reported in the button area to the finger count. Likewise we must also add fingers reported this way to the finger count when we get MULTI packets. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Cc: stable@vger.kernel.org # 3.17 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
The v7 proto differentiates between a primary touch (with high precision) and a secondary touch (with lower precision). Normally when 2 fingers are down and one is lifted the still present touch becomes the primary touch, but some traces have shown that this does not happen always. This commit deals with this by making alps_get_mt_count() not stop at the first empty mt slot, and if a touch is present in mt[1] and not mt[0] moving the data to mt[0] (for input_mt_assign_slots). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Cc: stable@vger.kernel.org # 3.17 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
NEW packets are send to indicate a discontinuity in the finger coordinate reporting. Specifically a finger may have moved from slot 0 to 1 or vice versa. INPUT_MT_TRACK takes care of this for us. NEW packets have 3 problems: 1) They do not contain middle / right button info (on non clickpads) this can be worked around by preserving the old button state 2) They do not contain an accurate fingercount, and they are typically send when the number of fingers changes. We cannot use the old finger count as that may mismatch with the amount of touch coordinates we've available in the NEW packet 3) Their x data for the second touch is inaccurate leading to a possible jump of the x coordinate by 16 units when the first non NEW packet comes in Since problems 2 & 3 cannot be worked around, just ignore them. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338 Cc: stable@vger.kernel.org # 3.17 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 14 11月, 2014 1 次提交
-
-
由 Pali Rohár 提交于
Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS protocol V3 packets with bit7 set in last byte. More often it can be reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing cover above touchpad. If bit7 in last packet byte is set then it is not valid ALPS packet. I was told that ALPS devices never send these packets. It is not know yet who send those packets, it could be Dell EC, bug in BIOS and also bug in touchpad firmware... With this patch alps driver does not process those invalid packets, but instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state, getting back in sync with the next byte and spam dmesg we return PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks on the next byte and report PSMOUSE_BAD_DATA then. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 10 11月, 2014 1 次提交
-
-
由 Pali Rohár 提交于
On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte in 6 bytes ALPS packet. In this case psmouse driver enter out of sync state. It looks like that all other bytes in packets are valid and also device working properly. So there is no need to do full device reset, just need to wait for byte which match condition for first byte (start of packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is small. This patch increase number of invalid bytes to size of 2 ALPS packets which psmouse driver can drop before do full reset. Resetting ALPS devices take some time and when doing reset on some Dell laptops touchpad, trackstick and also keyboard do not respond. So it is better to do it only if really necessary. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 09 11月, 2014 1 次提交
-
-
由 Pali Rohár 提交于
5th and 6th byte of ALPS trackstick V3 protocol match condition for first byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS trackstick is sending data then driver match 5th, 6th and next 1st bytes as PS/2. It basically means if user is using trackstick when driver is in out of sync state driver will never resync. Processing these bytes as 3 bytes PS/2 data cause total mess (random cursor movements, random clicks) and make trackstick unusable until psmouse driver decide to do full device reset. Lot of users reported problems with ALPS devices on Dell Latitude E6440, E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like that i8042 and psmouse/alps driver always receive group of 6 bytes packets so there are no missing bytes and no bytes were inserted between valid ones. This patch does not fix root of problem with ALPS devices found in Dell Latitude laptops but it does not allow to process some (invalid) subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of sync. So with this patch trackstick input device does not report bogus data when also driver is out of sync, so trackstick should be usable on those machines. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 16 10月, 2014 1 次提交
-
-
由 Andreas Bosch 提交于
Since the change to struct input_mt_pos some variables are now bitfields instead of integers. Automatic conversion from integer to bitfield entry destroys information, therefore enforce boolean interpretation instead. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1114768 Fixes: 02d04254 ("Input: alps - use struct input_mt_pos to track coordinates") Signed-off-by: NAndreas Bosch <linux@progandy.de> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 09 9月, 2014 2 次提交
-
-
由 Hans de Goede 提交于
I've not done a full audit of all mouse drivers, I noticed these ones were missing the POINTER property while working on the POINTING_STICK property. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
It is useful for userspace to know that there not dealing with a regular mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace can e.g. automatically enable middle button scrollwheel emulation. It is impossible to tell the difference from the evdev info without resorting to putting a list of device / driver names in userspace, this is undesirable. Add a property which allows userspace to see if a device is a pointing stick, and set it on all the pointing stick drivers. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NPeter Hutterer <peter.hutterer@who-t.net> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 27 8月, 2014 1 次提交
-
-
由 Dmitry Torokhov 提交于
When we fail to match data returned by E7 and EC reports we state that we found "Unknown ALPS touchpad" whereas it is most likely it is not ALPS touchpad at all. Change wording a bit and reduce the message to debug so that it does not litter users logs and confuse them. Reported-by: NPaul Menzel <paulepanter@users.sourceforge.net> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 31 7月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
Add support for querying the physical size from the touchpad for Rushmore and v7 touchpads, and use that to tell userspace the device resolution. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 27 7月, 2014 12 次提交
-
-
由 Yunkang Tang 提交于
Such as found on the new Toshiba Portégé Z30-A and Z40-A. Signed-off-by: NYunkang 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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
So that decode functions can return a failure when appropriate. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Move all the semi-mt specific handling shared between the v3 and v4 handling code to a common helper function. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Factor out the identical code for getting the bitmap points for x and y into a helper function. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-