[PATCH] hid-gfrm: Google Fiber TV Box remote controls

2015-10-21 Thread Petri Gynther 
Add HID driver for Google Fiber TV Box remote controls

Signed-off-by: Petri Gynther 
---
 drivers/hid/Kconfig|   6 ++
 drivers/hid/Makefile   |   1 +
 drivers/hid/hid-gfrm.c | 158 +
 3 files changed, 165 insertions(+)
 create mode 100644 drivers/hid/hid-gfrm.c

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 6ab51ae..7245b7f 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -257,6 +257,12 @@ config HID_GEMBIRD
---help---
Support for Gembird JPD-DualForce 2.
 
+config HID_GFRM
+   tristate "Google Fiber TV Box remote control support"
+   depends on HID
+   ---help---
+   Support for Google Fiber TV Box remote controls
+
 config HID_HOLTEK
tristate "Holtek HID devices"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index e6441bc..571d176 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_HID_ELECOM)  += hid-elecom.o
 obj-$(CONFIG_HID_ELO)  += hid-elo.o
 obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
 obj-$(CONFIG_HID_GEMBIRD)  += hid-gembird.o
+obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
 obj-$(CONFIG_HID_GT683R)   += hid-gt683r.o
 obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
 obj-$(CONFIG_HID_HOLTEK)   += hid-holtek-kbd.o
diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
new file mode 100644
index 000..4d7b7e7
--- /dev/null
+++ b/drivers/hid/hid-gfrm.c
@@ -0,0 +1,158 @@
+/*
+ * HID driver for Google Fiber TV Box remote controls
+ *
+ * Copyright (c) 2014-2015 Google Inc.
+ *
+ * Author: Petri Gynther 
+ *
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "hid-ids.h"
+
+#define GFRM100  1  /* Google Fiber GFRM100 (Bluetooth classic) */
+#define GFRM200  2  /* Google Fiber GFRM200 (Bluetooth LE) */
+
+#define GFRM100_SEARCH_KEY_REPORT_ID   0xF7
+#define GFRM100_SEARCH_KEY_DOWN0x0
+#define GFRM100_SEARCH_KEY_AUDIO_DATA  0x1
+#define GFRM100_SEARCH_KEY_UP  0x2
+
+static u8 search_key_dn[3] = {0x40, 0x21, 0x02};
+static u8 search_key_up[3] = {0x40, 0x00, 0x00};
+
+static int gfrm_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+   struct hid_field *field, struct hid_usage *usage,
+   unsigned long **bit, int *max)
+{
+   unsigned long hdev_type = (unsigned long) hid_get_drvdata(hdev);
+
+   if (hdev_type == GFRM100) {
+   if (usage->hid == (HID_UP_CONSUMER | 0x4)) {
+   /* Consumer.0004 -> KEY_INFO */
+   hid_map_usage_clear(hi, usage, bit, max, EV_KEY, 
KEY_INFO);
+   return 1;
+   }
+
+   if (usage->hid == (HID_UP_CONSUMER | 0x41)) {
+   /* Consumer.0041 -> KEY_OK */
+   hid_map_usage_clear(hi, usage, bit, max, EV_KEY, 
KEY_OK);
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
+   u8 *data, int size)
+{
+   unsigned long hdev_type = (unsigned long) hid_get_drvdata(hdev);
+   int ret = 0;
+
+   if (hdev_type != GFRM100)
+   return 0;
+
+   if (size < 2 || data[0] != GFRM100_SEARCH_KEY_REPORT_ID)
+   return 0;
+
+   /*
+* Convert GFRM100 Search key reports into Consumer.0221 (Key.Search)
+* reports. Ignore audio data.
+*/
+   switch (data[1]) {
+   case GFRM100_SEARCH_KEY_DOWN:
+   ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, 
search_key_dn,
+  sizeof(search_key_dn), 1);
+   break;
+
+   case GFRM100_SEARCH_KEY_AUDIO_DATA:
+   break;
+
+   case GFRM100_SEARCH_KEY_UP:
+   ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, 
search_key_up,
+  sizeof(search_key_up), 1);
+   break;
+
+   default:
+   break;
+   }
+
+   return (ret < 0) ? ret : -1;
+}
+
+static void gfrm_input_configured(struct hid_device *hid, struct hid_input 
*hidinput)
+{
+   /*
+* Enable software autorepeat with:
+* - repeat delay: 400 msec
+* - repeat period: 100 msec
+*/
+   input_enable_softrepeat(hidinput->input, 400, 100);
+}
+
+static int gfrm_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+   int ret;
+
+   hid_set_drvdata(hdev, (void *) id->driver_data);
+
+   ret = hid_parse(hdev);
+   if (ret)
+   goto done;
+
+   if

Re: [PATCH] hid-gfrm: Google Fiber TV Box remote controls

2015-10-21 Thread Petri Gynther 
On Wed, Oct 21, 2015 at 12:04 PM, Petri Gynther  wrote:
>
> Add HID driver for Google Fiber TV Box remote controls
>
> Signed-off-by: Petri Gynther 
> ---
>  drivers/hid/Kconfig|   6 ++
>  drivers/hid/Makefile   |   1 +
>  drivers/hid/hid-gfrm.c | 158 
> +
>  3 files changed, 165 insertions(+)
>  create mode 100644 drivers/hid/hid-gfrm.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 6ab51ae..7245b7f 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -257,6 +257,12 @@ config HID_GEMBIRD
> ---help---
> Support for Gembird JPD-DualForce 2.
>
> +config HID_GFRM
> +   tristate "Google Fiber TV Box remote control support"
> +   depends on HID
> +   ---help---
> +   Support for Google Fiber TV Box remote controls
> +
>  config HID_HOLTEK
> tristate "Holtek HID devices"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index e6441bc..571d176 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_HID_ELECOM)  += hid-elecom.o
>  obj-$(CONFIG_HID_ELO)  += hid-elo.o
>  obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
>  obj-$(CONFIG_HID_GEMBIRD)  += hid-gembird.o
> +obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
>  obj-$(CONFIG_HID_GT683R)   += hid-gt683r.o
>  obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
>  obj-$(CONFIG_HID_HOLTEK)   += hid-holtek-kbd.o
> diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
> new file mode 100644
> index 000..4d7b7e7
> --- /dev/null
> +++ b/drivers/hid/hid-gfrm.c
> @@ -0,0 +1,158 @@
> +/*
> + * HID driver for Google Fiber TV Box remote controls
> + *
> + * Copyright (c) 2014-2015 Google Inc.
> + *
> + * Author: Petri Gynther 
> + *
> + * 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.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "hid-ids.h"
> +
> +#define GFRM100  1  /* Google Fiber GFRM100 (Bluetooth classic) */
> +#define GFRM200  2  /* Google Fiber GFRM200 (Bluetooth LE) */
> +
> +#define GFRM100_SEARCH_KEY_REPORT_ID   0xF7
> +#define GFRM100_SEARCH_KEY_DOWN0x0
> +#define GFRM100_SEARCH_KEY_AUDIO_DATA  0x1
> +#define GFRM100_SEARCH_KEY_UP  0x2
> +
> +static u8 search_key_dn[3] = {0x40, 0x21, 0x02};
> +static u8 search_key_up[3] = {0x40, 0x00, 0x00};
> +
> +static int gfrm_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> +   struct hid_field *field, struct hid_usage *usage,
> +   unsigned long **bit, int *max)
> +{
> +   unsigned long hdev_type = (unsigned long) hid_get_drvdata(hdev);
> +
> +   if (hdev_type == GFRM100) {
> +   if (usage->hid == (HID_UP_CONSUMER | 0x4)) {
> +   /* Consumer.0004 -> KEY_INFO */
> +   hid_map_usage_clear(hi, usage, bit, max, EV_KEY, 
> KEY_INFO);
> +   return 1;
> +   }
> +
> +   if (usage->hid == (HID_UP_CONSUMER | 0x41)) {
> +   /* Consumer.0041 -> KEY_OK */
> +   hid_map_usage_clear(hi, usage, bit, max, EV_KEY, 
> KEY_OK);
> +   return 1;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
> +static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
> +   u8 *data, int size)
> +{
> +   unsigned long hdev_type = (unsigned long) hid_get_drvdata(hdev);
> +   int ret = 0;
> +
> +   if (hdev_type != GFRM100)
> +   return 0;
> +
> +   if (size < 2 || data[0] != GFRM100_SEARCH_KEY_REPORT_ID)
> +   return 0;
> +
> +   /*
> +* Convert GFRM100 Search key reports into Consumer.0221 (Key.Search)
> +* reports. Ignore audio data.
> +*/
> +   switch (data[1]) {
> +   case GFRM100_SEARCH_KEY_DOWN:
> +   ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, 
> search_key_dn,
> +  sizeof(search_key_dn), 1);
> +   break;
> +
> +   case GFRM100_SEARCH_KEY_AUDIO_DATA:
> +   break;
> +
> +   case GFRM100_SEARCH_KEY_UP:
> +   ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, 
> search_key_up,
> +  sizeof(search_key_up), 1);
> +   break;
> +
> +   default:
> +   break;
> +   }
> +
> +   return (ret < 0) ? ret : -1;
> +}
> +
> +static void gfrm_input_configured(struct hid_device *hid, struct hid_input 
> *hidinput)
> +{
> +   /*
> +* Enable software autorepeat with:
> +* - repeat delay: 400 msec
> +

Re: [PATCH v3] HID: wacom: Add support for Cintiq Companion 2

2015-10-21 Thread Jiri Kosina 
On Tue, 13 Oct 2015, Jason Gerecke wrote:

> Adds support for the EMR (pen+pad) and touchscreen devices used by the
> Wacom Cintiq Companion 2. This applies both to using the device as a
> standalone system, as well as when operating in "Cintiq mode" (where
> the EMR/touchscreen are simply exposed as USB devices to the system
> its connected to).
> 
> Signed-off-by: Jason Gerecke 
> Signed-off-by: Clifford Jolly 
> ---
> Changes from v2:
>  * The switch in wacom_setup_pen_input_capabilities now only contains the
>first CINTIQ_COMPANION_2 case. The second case has been moved to the
>switch in wacom_setup_pad_input_capabilities where it belongs.
> 
>  * The second CINTIQ_COMPANION_2 case mentioned above no longer explicitly
>sets up the pad buttons since wacom_setup_numbered_buttons is now
>(70ee06c) in charge of this initialization.

Applied to for-4.4/wacom.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HID: wacom: Report full pressure range for Intuos, Cintiq 13HD Touch

2015-10-21 Thread Jiri Kosina 
On Thu, 15 Oct 2015, Jason Gerecke wrote:

> The new Intuos tablets added in eda01da and the Cintiq 13HD Touch added
> in b4bf212 are capable of reporting 2048 levels of pressure. Although the
> kernel reports the correct range to userspace, an oversight has resulted
> in the driver ingoring the 11th pressure bit and only sending pressures
> of 0 through 1023.
> 
> We could fix this issue by expanding the type check to include these
> devices, but it makes much more sense to just have the driver look at
> the device's maximum pressure when determining if it should read the
> 11th bit.
> 
> Signed-off-by: Jason Gerecke 

Applied to for-4.4/wacom.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HID: roccat: Fixed resubmit: Deprecating most Roccat sysfs attributes

2015-10-21 Thread Jiri Kosina 
On Sat, 17 Oct 2015, Stefan Achatz wrote:

> Deprecates all Roccat sysfs attributes except the ones for the old Kone by 
> moving
> abi descriptions from testing to obsolete.
> For most devices everything can be done using the hidraw ioctls HIDIOCGFEATURE
> and HIDIOCSFEATURE, so I would suggest future removal of device specific 
> drivers.
> The userspace tools don't use these attributes for a year now.
> The first Kone is not fully HID-compliant and will still need a module.

Ok, I am queuing this in for-4.4/roccat-sysfs-deprecation, let's see how 
this goes.

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/19] input: tegra-kbc: enable support for the standard "wakeup-source" property

2015-10-21 Thread Sudeep Holla 
Though the mmc core driver should/will continue to support the legacy
"nvidia,wakeup-source" property to enable SDIO as the wakeup source, we
need to add support for the new standard property "wakeup-source".

This patch adds support for "wakeup-source" property in addition to the
existing "nvidia,wakeup-source" property.

Cc: Laxman Dewangan 
Cc: Dmitry Torokhov 
Cc: Thierry Reding 
Cc: linux-input@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 drivers/input/keyboard/tegra-kbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/tegra-kbc.c 
b/drivers/input/keyboard/tegra-kbc.c
index f97c73bd14f8..f80c72d4ac8f 100644
--- a/drivers/input/keyboard/tegra-kbc.c
+++ b/drivers/input/keyboard/tegra-kbc.c
@@ -517,7 +517,8 @@ static int tegra_kbc_parse_dt(struct tegra_kbc *kbc)
if (of_find_property(np, "nvidia,needs-ghost-filter", NULL))
kbc->use_ghost_filter = true;
 
-   if (of_find_property(np, "nvidia,wakeup-source", NULL))
+   if (of_property_read_bool(np, "wakeup-source") ||
+   of_property_read_bool(np, "nvidia,wakeup-source")) /* legacy */
kbc->wakeup = true;
 
if (!of_get_property(np, "nvidia,kbc-row-pins", )) {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3 0/3] Input: goodix - add axis swapping and axis inversion support

2015-10-21 Thread Aleksei Mamlin 
On Sun, 18 Oct 2015 17:52:56 +0200
Karsten Merker  wrote:

> Hello,
> 
> this is v3 of my "Input: goodix - add axis swapping and axis inversion
> support" patchset.
> 
> The goodix touchscreen driver has gained device-tree support in kernel
> 4.1, but doesn't currently support the touchscreen-swapped-x-y,
> touchscreen-inverted-x and touchscreen-inverted-y properties.
> On systems which combine a portrait-mode display with a landscape-mode
> touchscreen, such as e.g. the MSI Primo 81 tablet, support for these
> features is necessary to have the touchscreen and the display use the
> same coordinate system.
> 
> With support for axis inversion, the "rotated_screen" flag in the
> driver can also be removed, as "rotated_screen" is just a special case
> of x/y axis inversion.
> 
> This patchset sits on top of the "[PATCH v9 0/9] Goodix touchscreen
> enhancements" series by Irina Tirdea:
> https://www.spinics.net/lists/linux-input/msg41501.html
> 
> The axis swapping has successfully been tested on an (arm-based)
> MSI Primo 81 tablet; the x/y inversion resp. the rotated_screen
> functionality has successfully been tested on a WinBook TW100.
> 
> @Bastien: You had acked patch No. 1 in v2 of the patchset. I have
>   not transferred that ack to v3 of the same patch
>   because I have have introduced some changes into that
>   patch (based on Irina's review comments, cf. the
>   changelog below) after your ack.  I would apprechiate
>   very much if you could take a look and tell me whether
>   your ack extends to v3 as well.
> 
> Regards,
> Karsten
> 
> Changelog:
> 
> v1: * Initial version (based von v6 of Irina Tirdea's "Goodix
>   touchscreen enhancements" series).
>   Reviewed-by: Bastien Nocera 
> 
> v2: * Rebase against v8 of Irina Tirdea's "Goodix touchscreen
>   enhancements" series.
> * Fix a typo in the commit message.
> * Add an update for the goodix dt bindings documentation
>   (patch No. 3).
> * Reviews/Tests:
>   Patch 1+2: Tested-by: Bastien Nocera 
>  Acked-by: Bastien Nocera 
>   Patch 2+3: Reviewed-by: Irina Tirdea 
> 
> v3: * Rebase against v9 of Irina Tirdea's "Goodix touchscreen
>   enhancements" series.
> * Address the review comments for patch No. 1 by Irina Tirdea
>   (https://www.spinics.net/lists/linux-input/msg41536.html):
>   - Move reading the dt properties from goodix_ts_probe to
> goodix_configure_dev to make them work properly in all
> configurations (with and without gpio declarations).
>   - Use the new unified device properties API (device_property_*)
> instead of the classic DT API (of_property_*). This
> provides support for ACPI 5.1 DSD properties as well as 
> for device-tree properties.
> 
> Karsten Merker (3):
>   Input: goodix - add axis swapping and axis inversion support
>   Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen"
>   Input: goodix - update dt bindings documentation (axis
> swapping/inversion)
> 
>  .../bindings/input/touchscreen/goodix.txt  |  6 +
>  drivers/input/touchscreen/goodix.c | 31 
> ++
>  2 files changed, 32 insertions(+), 5 deletions(-)
> 
> -- 
> 2.1.4

Tested on Wexler TAB7200 with device-tree properties.

Tested-by: Aleksei Mamlin 


-- 
Thanks and regards,
Aleksei Mamlin
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] HID: wacom: Expect 'touch_max' touches if HID_DG_CONTACTCOUNT not present

2015-10-21 Thread Jiri Kosina 
On Wed, 7 Oct 2015, Jason Gerecke wrote:

> When introduced in commit 1b5d514, the check 'if (hid_data->cc_index >= 0)'
> in 'wacom_wac_finger_pre_report' was intended to switch where the driver
> got the expected number of contacts from: HID_DG_CONTACTCOUNT if the usage
> was present, or 'touch_max' otherwise. Unfortunately, an oversight worthy
> of a brown paper bag (specifically, that 'cc_index' could never be negative)
> meant that the latter 'else' clause would never be entered.
> 
> The patch prior to this one introduced a way for 'cc_index' to be negative,
> but only if HID_DG_CONTACTCOUNT is present in some report _other_ than the
> one being processed. To ensure the 'else' clause is also entered for devices
> which don't have HID_DG_CONTACTCOUNT on _any_ report, we add the additional
> constraint that 'cc_report' be non-zero (which is true only if the usage is
> present in some report).
> 
> Signed-off-by: Jason Gerecke 
> ---
> Jiri,
> 
> Could you please queue this patch and the prior for 4.3? They fix issues
> with the implementation of my "Ignore contacts in excess of declared
> contact count" patch which was pulled in as part of the 4.3 merge window.

Alright, I've applied this to for-4.3/upstream-fixes, but it's now very 
late in the cycle, so I am not 100% sure this patch will make it into 4.3. 
Hence I've added -stable annotation to it so that it's picked by first 
4.3-stable afterwards in such case.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] HID: fix some indenting issues

2015-10-21 Thread Jiri Kosina 
On Sun, 11 Oct 2015, Jiri Slaby wrote:

> Some drivers indent some lines in a very weird manner. Fix that.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Josenivaldo Benito Junior 
> Cc: Franco Catrin 
> Cc: Nikolai Kondrashov 
> Cc: Don Prince 
> Cc: srinivas pandruvada 

Some of the are not really worth it per se, but the ones in 
aureal_report_fixup() and sensor_hub_*() are annoying enough to make the 
code harder to read, so I am applying it as a whole.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HID: reject input outside logical range only if null state is set

2015-10-21 Thread Jiri Kosina 
On Tue, 13 Oct 2015, r...@nic.fi wrote:

> Kernel 3.19.0 one-line fix for an issue in drivers/hid/hid-input.c where USB
> HID control null state flag is not checked when rejecting inputs outside
> logical minimum-maximum range. The check should be made as per USB HID
> specification 1.11, section 6.2.2.5, p.31. I have no resources for large-scale
> testing, but this fixes problems with the game controller I have (INNEX NES
> Controller USB).
> 
> More details: https://bugzilla.kernel.org/show_bug.cgi?id=68621
> 
> 
> Signed-Off-by: Valtteri Heikkilä 
> --- a/drivers/hid/hid-input.c 2015-05-25 09:58:49.743527141 +0800
> +++ b/drivers/hid/hid-input.c 2015-05-25 11:04:13.201191432 +0800
> @@ -1097,6 +1097,7 @@
> * don't specify logical min and max.
> */
> if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
> + (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
> (field->logical_minimum < field->logical_maximum) &&
> (value < field->logical_minimum ||
> value > field->logical_maximum)) {

Your patch has been corrupted by your mailer badly. Please try to fix it 
(some hints are in Documentation/email-clients.txt) and resubmit.

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] alps: Only the Dell Latitude D420/430/620/630 have separate stick button bits

2015-10-21 Thread Hans de Goede 
commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has
separate stick button bits") assumes that all alps v2 non-interleaved
dual point setups have the separate stick button bits.

Later we limited this to Dell laptops only because of reports that this
broke things on non Dell laptops. Now it turns out that this breaks things
on the Dell Latitude D600 too. So it seems that only the Dell Latitude
D420/430/620/630, which all share the same touchpad / stick combo,
have these separate bits.

This patch limits the checking of the separate bits to only these models
fixing regressions with other models.

Reported-and-tested-by: Larry Finger 
Cc: sta...@vger.kernel.org
Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
---
 drivers/input/mouse/alps.c | 48 --
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 4d24686..41e6cb5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -100,7 +100,7 @@ static const struct alps_nibble_commands 
alps_v6_nibble_commands[] = {
 #define ALPS_FOUR_BUTTONS  0x40/* 4 direction button present */
 #define ALPS_PS2_INTERLEAVED   0x80/* 3-byte PS/2 packet interleaved with
   6-byte ALPS packet */
-#define ALPS_DELL  0x100   /* device is a Dell laptop */
+#define ALPS_STICK_BITS0x100   /* separate stick button bits */
 #define ALPS_BUTTONPAD 0x200   /* device is a clickpad */
 
 static const struct alps_model_info alps_model_data[] = {
@@ -159,6 +159,43 @@ static const struct alps_protocol_info 
alps_v8_protocol_data = {
ALPS_PROTO_V8, 0x18, 0x18, 0
 };
 
+/*
+ * Some v2 models report the stick buttons in separate bits
+ */
+static const struct dmi_system_id alps_dmi_has_separate_stick_buttons[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+   {
+   /* Extrapolated from other entries */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D420"),
+   },
+   },
+   {
+   /* Reported-by: Hans de Bruin  */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D430"),
+   },
+   },
+   {
+   /* Reported-by: Hans de Goede  */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D620"),
+   },
+   },
+   {
+   /* Extrapolated from other entries */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D630"),
+   },
+   },
+#endif
+   { }
+};
+
 static void alps_set_abs_params_st(struct alps_data *priv,
   struct input_dev *dev1);
 static void alps_set_abs_params_semi_mt(struct alps_data *priv,
@@ -253,9 +290,8 @@ static void alps_process_packet_v1_v2(struct psmouse 
*psmouse)
return;
}
 
-   /* Dell non interleaved V2 dualpoint has separate stick button bits */
-   if (priv->proto_version == ALPS_PROTO_V2 &&
-   priv->flags == (ALPS_DELL | ALPS_PASS | ALPS_DUALPOINT)) {
+   /* Some models have separate stick button bits */
+   if (priv->flags & ALPS_STICK_BITS) {
left |= packet[0] & 1;
right |= packet[0] & 2;
middle |= packet[0] & 4;
@@ -2552,8 +2588,6 @@ static int alps_set_protocol(struct psmouse *psmouse,
priv->byte0 = protocol->byte0;
priv->mask0 = protocol->mask0;
priv->flags = protocol->flags;
-   if (dmi_name_in_vendors("Dell"))
-   priv->flags |= ALPS_DELL;
 
priv->x_max = 2000;
priv->y_max = 1400;
@@ -2568,6 +2602,8 @@ static int alps_set_protocol(struct psmouse *psmouse,
priv->set_abs_params = alps_set_abs_params_st;
priv->x_max = 1023;
priv->y_max = 767;
+   if (dmi_check_system(alps_dmi_has_separate_stick_buttons))
+   priv->flags |= ALPS_STICK_BITS;
break;
 
case ALPS_PROTO_V3:
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression since commit 92bac83

2015-10-21 Thread Pali Rohár 
On Wednesday 21 October 2015 10:30:47 Hans de Goede wrote:
> >Hi! Are you sure that above machines do not have variants without
> >ALPS_DUALPOINT or without ALPS_PASS? Because if yes, then we could see
> >another break.
> 
> Yes I'm sure that these machines always come with a dualpoint setup
> with pass-through support.

Ok, in this case, I'm fine with this patch. Hopefully no other obscure
problem will be reported...

So you can add my Acked-By: Pali Rohár 

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression since commit 92bac83

2015-10-21 Thread Pali Rohár 
On Tuesday 20 October 2015 13:39:05 Hans de Goede wrote:
> From 5d21a8004260c3e6287bde81c2a9e8f80144e77c Mon Sep 17 00:00:00 2001
> From: Hans de Goede 
> Date: Tue, 20 Oct 2015 11:12:07 +0200
> Subject: [PATCH] alps: Only the Dell Latitude D420/430/620/630 have separate
>  stick button bits
> 
> commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has
> separate stick button bits") assumes that all alps v2 non-interleaved
> dual point setups have the separate stick button bits.
> 
> Later we limited this to Dell laptops only because of reports that this
> broke things on non Dell laptops. Now it turns out that this breaks things
> on the Dell Latitude D600 too. So it seems that only the Dell Latitude
> D420/430/620/630, which all share the same touchpad / stick combo,
> have these separate bits.
> 
> This patch limits the checking of the separate bits to only these models
> fixing regressions with other models.
> 
> Reported-and-tested-by: Larry Finger 
> Cc: sta...@vger.kernel.org
> Tested-by: Hans de Goede 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/input/mouse/alps.c | 48 
> --
>  1 file changed, 42 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 4d24686..41e6cb5 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -100,7 +100,7 @@ static const struct alps_nibble_commands 
> alps_v6_nibble_commands[] = {
>  #define ALPS_FOUR_BUTTONS0x40/* 4 direction button present */
>  #define ALPS_PS2_INTERLEAVED 0x80/* 3-byte PS/2 packet interleaved with
>  6-byte ALPS packet */
> -#define ALPS_DELL0x100   /* device is a Dell laptop */
> +#define ALPS_STICK_BITS  0x100   /* separate stick button bits */
>  #define ALPS_BUTTONPAD   0x200   /* device is a clickpad */
>  
>  static const struct alps_model_info alps_model_data[] = {
> @@ -159,6 +159,43 @@ static const struct alps_protocol_info 
> alps_v8_protocol_data = {
>   ALPS_PROTO_V8, 0x18, 0x18, 0
>  };
>  
> +/*
> + * Some v2 models report the stick buttons in separate bits
> + */
> +static const struct dmi_system_id alps_dmi_has_separate_stick_buttons[] = {
> +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> + {
> + /* Extrapolated from other entries */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D420"),
> + },
> + },
> + {
> + /* Reported-by: Hans de Bruin  */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D430"),
> + },
> + },
> + {
> + /* Reported-by: Hans de Goede  */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D620"),
> + },
> + },
> + {
> + /* Extrapolated from other entries */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D630"),
> + },
> + },
> +#endif
> + { }
> +};
> +

Hi! Are you sure that above machines do not have variants without
ALPS_DUALPOINT or without ALPS_PASS? Because if yes, then we could see
another break.

>  static void alps_set_abs_params_st(struct alps_data *priv,
>  struct input_dev *dev1);
>  static void alps_set_abs_params_semi_mt(struct alps_data *priv,
> @@ -253,9 +290,8 @@ static void alps_process_packet_v1_v2(struct psmouse 
> *psmouse)
>   return;
>   }
>  
> - /* Dell non interleaved V2 dualpoint has separate stick button bits */
> - if (priv->proto_version == ALPS_PROTO_V2 &&
> - priv->flags == (ALPS_DELL | ALPS_PASS | ALPS_DUALPOINT)) {
> + /* Some models have separate stick button bits */
> + if (priv->flags & ALPS_STICK_BITS) {

Previous code checked at this place if device has also flags ALPS_PASS
and ALPS_DUALPOINT. Now ALPS_STICK_BITS is defined only if ALPS_PROTO_V2
and DMI has specific Dell machine.

>   left |= packet[0] & 1;
>   right |= packet[0] & 2;
>   middle |= packet[0] & 4;
> @@ -2552,8 +2588,6 @@ static int alps_set_protocol(struct psmouse *psmouse,
>   priv->byte0 = protocol->byte0;
>   priv->mask0 = protocol->mask0;
>   priv->flags = protocol->flags;
> - if (dmi_name_in_vendors("Dell"))
> - priv->flags |= ALPS_DELL;
>  
>   priv->x_max = 2000;
>   priv->y_max = 1400;
> @@ -2568,6 +2602,8 @@ static int alps_set_protocol(struct

Re: Regression since commit 92bac83

2015-10-21 Thread Hans de Goede 

Hi,

On 21-10-15 10:19, Pali Rohár wrote:

On Tuesday 20 October 2015 13:39:05 Hans de Goede wrote:

 From 5d21a8004260c3e6287bde81c2a9e8f80144e77c Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Tue, 20 Oct 2015 11:12:07 +0200
Subject: [PATCH] alps: Only the Dell Latitude D420/430/620/630 have separate
  stick button bits

commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has
separate stick button bits") assumes that all alps v2 non-interleaved
dual point setups have the separate stick button bits.

Later we limited this to Dell laptops only because of reports that this
broke things on non Dell laptops. Now it turns out that this breaks things
on the Dell Latitude D600 too. So it seems that only the Dell Latitude
D420/430/620/630, which all share the same touchpad / stick combo,
have these separate bits.

This patch limits the checking of the separate bits to only these models
fixing regressions with other models.

Reported-and-tested-by: Larry Finger 
Cc: sta...@vger.kernel.org
Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
---
  drivers/input/mouse/alps.c | 48 --
  1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 4d24686..41e6cb5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -100,7 +100,7 @@ static const struct alps_nibble_commands 
alps_v6_nibble_commands[] = {
  #define ALPS_FOUR_BUTTONS 0x40/* 4 direction button present */
  #define ALPS_PS2_INTERLEAVED  0x80/* 3-byte PS/2 packet interleaved with
   6-byte ALPS packet */
-#define ALPS_DELL  0x100   /* device is a Dell laptop */
+#define ALPS_STICK_BITS0x100   /* separate stick button bits */
  #define ALPS_BUTTONPAD0x200   /* device is a clickpad */

  static const struct alps_model_info alps_model_data[] = {
@@ -159,6 +159,43 @@ static const struct alps_protocol_info 
alps_v8_protocol_data = {
ALPS_PROTO_V8, 0x18, 0x18, 0
  };

+/*
+ * Some v2 models report the stick buttons in separate bits
+ */
+static const struct dmi_system_id alps_dmi_has_separate_stick_buttons[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+   {
+   /* Extrapolated from other entries */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D420"),
+   },
+   },
+   {
+   /* Reported-by: Hans de Bruin  */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D430"),
+   },
+   },
+   {
+   /* Reported-by: Hans de Goede  */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D620"),
+   },
+   },
+   {
+   /* Extrapolated from other entries */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D630"),
+   },
+   },
+#endif
+   { }
+};
+


Hi! Are you sure that above machines do not have variants without
ALPS_DUALPOINT or without ALPS_PASS? Because if yes, then we could see
another break.


Yes I'm sure that these machines always come with a dualpoint setup
with pass-through support. The 20/30 models are in essence the same
with just a newer version core2duo dropped in (they changed the model
now since the newer core2duo-s where the first x86_64 cpu-s from Intel,
and the 4x0 / 6x0 models have the exact same dualpoint setup, which is
why both Hans de Bruin and me were seeing the same bug.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Y2038] [PATCH] hp_sdc: fixed y2038 problem

2015-10-21 Thread Pingbo Wen 


On Monday, October 19, 2015 05:01 PM, Arnd Bergmann wrote:
> On Sunday 18 October 2015 17:44:19 WEN Pingbo wrote:
>> Two replacements happened in this patch:
>> 1. using timespec64 to prevent time overflow in 2038
>> 2. using ktime_get_ts64 to avoid wall time issues(leap second, etc)
>>
>> Signed-off-by: WEN Pingbo 
>>
> 
> The patch looks correct, but I think this could be written a little
> simpler and clearer using ktime_get() or ktime_getns().
> 

That make sense, Maybe it can save a sec shift operation. I will check it later.

Pingbo
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html