* [PATCH] Input: add regulator haptic driver
From: hyunhee.kim @ 2013-10-11 2:22 UTC (permalink / raw)
To: dmitry.torokhov, broonie, peter.ujfalusi, wfp5p, linux-input,
linux-kernel, akpm
From: Hyunhee Kim <hyunhee.kim@samsung.com>
Date: Wed, 9 Oct 2013 16:21:36 +0900
Subject: [PATCH] Input: add regulator haptic driver
The regulator haptic driver function can be used to control motor by on/off
regulator.
User can control the haptic driver by using force feedback framework.
Signed-off-by: Hyunhee Kim <hyunhee.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/input/misc/Kconfig | 6 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/regulator-haptic.c | 185
+++++++++++++++++++++++++++++++++
3 files changed, 192 insertions(+)
create mode 100644 drivers/input/misc/regulator-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index bb698e1..f391cd7 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -82,6 +82,12 @@ config INPUT_ARIZONA_HAPTICS
To compile this driver as a module, choose M here: the
module will be called arizona-haptics.
+config INPUT_REGULATOR_HAPTIC
+ tristate "regulator haptics support"
+ select INPUT_FF_MEMLESS
+ help
+ Say Y to enable support for the haptics module for regulator.
+
config INPUT_BMA150
tristate "BMA150/SMB380 acceleration sensor support"
depends on I2C
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index d7fc17f..106f0bc 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X_I2C) +=
adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI) += adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS) += arizona-haptics.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_ATI_REMOTE2) += ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
obj-$(CONFIG_INPUT_BFIN_ROTARY) += bfin_rotary.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 0000000..29f57ea
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,185 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/regulator/driver.h>
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct work_struct work;
+ bool enabled;
+ struct regulator *regulator;
+ struct mutex mutex;
+ int level;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
enable)
+{
+ int ret;
+
+ mutex_lock(&haptic->mutex);
+ if (enable && !haptic->enabled) {
+ haptic->enabled = true;
+ ret = regulator_enable(haptic->regulator);
+ if (ret)
+ pr_err("haptic: %s failed to enable regulator\n",
+ __func__);
+ } else if (!enable && haptic->enabled) {
+ haptic->enabled = false;
+ ret = regulator_disable(haptic->regulator);
+ if (ret)
+ pr_err("haptic: %s failed to disable regulator\n",
+ __func__);
+ }
+ mutex_unlock(&haptic->mutex);
+}
+
+static void regulator_haptic_work(struct work_struct *work)
+{
+ struct regulator_haptic *haptic = container_of(work,
+ struct
regulator_haptic,
+ work);
+ if (haptic->level)
+ regulator_haptic_enable(haptic, true);
+ else
+ regulator_haptic_enable(haptic, false);
+
+}
+
+static int regulator_haptic_play(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ haptic->level = effect->u.rumble.strong_magnitude;
+ if (!haptic->level)
+ haptic->level = effect->u.rumble.weak_magnitude;
+ schedule_work(&haptic->work);
+
+ return 0;
+}
+
+static void regulator_haptic_close(struct input_dev *input)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ cancel_work_sync(&haptic->work);
+ regulator_haptic_enable(haptic, false);
+}
+
+static int regulator_haptic_probe(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic;
+ struct input_dev *input_dev;
+ int error;
+
+ haptic = kzalloc(sizeof(*haptic), GFP_KERNEL);
+ if (!haptic) {
+ dev_err(&pdev->dev, "unable to allocate memory for
haptic\n");
+ return -ENOMEM;
+ }
+
+ input_dev = input_allocate_device();
+
+ if (!input_dev) {
+ dev_err(&pdev->dev, "unable to allocate memory\n");
+ error = -ENOMEM;
+ goto err_kfree_mem;
+ }
+
+ INIT_WORK(&haptic->work, regulator_haptic_work);
+ mutex_init(&haptic->mutex);
+ haptic->input_dev = input_dev;
+ haptic->dev = &pdev->dev;
+ haptic->regulator = regulator_get(&pdev->dev, "haptic");
+
+ if (IS_ERR(haptic->regulator)) {
+ error = PTR_ERR(haptic->regulator);
+ dev_err(&pdev->dev, "unable to get regulator, err: %d\n",
+ error);
+ goto err_ifree_mem;
+ }
+
+ haptic->input_dev->name = "regulator:haptic";
+ haptic->input_dev->dev.parent = &pdev->dev;
+ haptic->input_dev->close = regulator_haptic_close;
+ haptic->enabled = false;
+ input_set_drvdata(haptic->input_dev, haptic);
+ input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
+
+ error = input_ff_create_memless(input_dev, NULL,
+ regulator_haptic_play);
+ if (error) {
+ dev_err(&pdev->dev,
+ "input_ff_create_memless() failed: %d\n",
+ error);
+ goto err_put_regulator;
+ }
+
+ error = input_register_device(haptic->input_dev);
+ if (error) {
+ dev_err(&pdev->dev,
+ "couldn't register input device: %d\n",
+ error);
+ goto err_destroy_ff;
+ }
+
+ platform_set_drvdata(pdev, haptic);
+
+ return 0;
+
+err_destroy_ff:
+ input_ff_destroy(haptic->input_dev);
+err_put_regulator:
+ regulator_put(haptic->regulator);
+err_ifree_mem:
+ input_free_device(haptic->input_dev);
+err_kfree_mem:
+ kfree(haptic);
+
+ return error;
+}
+
+static int regulator_haptic_remove(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
+
+ input_unregister_device(haptic->input_dev);
+
+ return 0;
+}
+
+static struct of_device_id regulator_haptic_dt_match[] = {
+ { .compatible = "linux,regulator-haptic" },
+ {},
+};
+
+static struct platform_driver regulator_haptic_driver = {
+ .driver = {
+ .name = "regulator-haptic",
+ .owner = THIS_MODULE,
+ .of_match_table = regulator_haptic_dt_match,
+ },
+
+ .probe = regulator_haptic_probe,
+ .remove = regulator_haptic_remove,
+};
+module_platform_driver(regulator_haptic_driver);
+
+MODULE_ALIAS("platform:regulator-haptic");
+MODULE_DESCRIPTION("Regulator haptic driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Hyunhee Kim <hyunhee.kim@samsung.com>");
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Input: add regulator haptic driver
From: hyunhee.kim @ 2013-10-11 2:26 UTC (permalink / raw)
To: dmitry.torokhov, broonie, peter.ujfalusi, wfp5p, linux-input,
linux-kernel, akpm
Cc: 'hyunhee.kim', kyungmin.park
From: Hyunhee Kim <hyunhee.kim@samsung.com>
Date: Wed, 9 Oct 2013 16:21:36 +0900
Subject: [PATCH] Input: add regulator haptic driver
The regulator haptic driver function can be used to control motor by on/off
regulator.
User can control the haptic driver by using force feedback framework.
Signed-off-by: Hyunhee Kim <hyunhee.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/input/misc/Kconfig | 6 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/regulator-haptic.c | 185
+++++++++++++++++++++++++++++++++
3 files changed, 192 insertions(+)
create mode 100644 drivers/input/misc/regulator-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index bb698e1..f391cd7 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -82,6 +82,12 @@ config INPUT_ARIZONA_HAPTICS
To compile this driver as a module, choose M here: the
module will be called arizona-haptics.
+config INPUT_REGULATOR_HAPTIC
+ tristate "regulator haptics support"
+ select INPUT_FF_MEMLESS
+ help
+ Say Y to enable support for the haptics module for regulator.
+
config INPUT_BMA150
tristate "BMA150/SMB380 acceleration sensor support"
depends on I2C
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index d7fc17f..106f0bc 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X_I2C) +=
adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI) += adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS) += arizona-haptics.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_ATI_REMOTE2) += ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
obj-$(CONFIG_INPUT_BFIN_ROTARY) += bfin_rotary.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 0000000..29f57ea
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,185 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/regulator/driver.h>
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct work_struct work;
+ bool enabled;
+ struct regulator *regulator;
+ struct mutex mutex;
+ int level;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
enable)
+{
+ int ret;
+
+ mutex_lock(&haptic->mutex);
+ if (enable && !haptic->enabled) {
+ haptic->enabled = true;
+ ret = regulator_enable(haptic->regulator);
+ if (ret)
+ pr_err("haptic: %s failed to enable regulator\n",
+ __func__);
+ } else if (!enable && haptic->enabled) {
+ haptic->enabled = false;
+ ret = regulator_disable(haptic->regulator);
+ if (ret)
+ pr_err("haptic: %s failed to disable regulator\n",
+ __func__);
+ }
+ mutex_unlock(&haptic->mutex);
+}
+
+static void regulator_haptic_work(struct work_struct *work)
+{
+ struct regulator_haptic *haptic = container_of(work,
+ struct
regulator_haptic,
+ work);
+ if (haptic->level)
+ regulator_haptic_enable(haptic, true);
+ else
+ regulator_haptic_enable(haptic, false);
+
+}
+
+static int regulator_haptic_play(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ haptic->level = effect->u.rumble.strong_magnitude;
+ if (!haptic->level)
+ haptic->level = effect->u.rumble.weak_magnitude;
+ schedule_work(&haptic->work);
+
+ return 0;
+}
+
+static void regulator_haptic_close(struct input_dev *input)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ cancel_work_sync(&haptic->work);
+ regulator_haptic_enable(haptic, false);
+}
+
+static int regulator_haptic_probe(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic;
+ struct input_dev *input_dev;
+ int error;
+
+ haptic = kzalloc(sizeof(*haptic), GFP_KERNEL);
+ if (!haptic) {
+ dev_err(&pdev->dev, "unable to allocate memory for
haptic\n");
+ return -ENOMEM;
+ }
+
+ input_dev = input_allocate_device();
+
+ if (!input_dev) {
+ dev_err(&pdev->dev, "unable to allocate memory\n");
+ error = -ENOMEM;
+ goto err_kfree_mem;
+ }
+
+ INIT_WORK(&haptic->work, regulator_haptic_work);
+ mutex_init(&haptic->mutex);
+ haptic->input_dev = input_dev;
+ haptic->dev = &pdev->dev;
+ haptic->regulator = regulator_get(&pdev->dev, "haptic");
+
+ if (IS_ERR(haptic->regulator)) {
+ error = PTR_ERR(haptic->regulator);
+ dev_err(&pdev->dev, "unable to get regulator, err: %d\n",
+ error);
+ goto err_ifree_mem;
+ }
+
+ haptic->input_dev->name = "regulator:haptic";
+ haptic->input_dev->dev.parent = &pdev->dev;
+ haptic->input_dev->close = regulator_haptic_close;
+ haptic->enabled = false;
+ input_set_drvdata(haptic->input_dev, haptic);
+ input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
+
+ error = input_ff_create_memless(input_dev, NULL,
+ regulator_haptic_play);
+ if (error) {
+ dev_err(&pdev->dev,
+ "input_ff_create_memless() failed: %d\n",
+ error);
+ goto err_put_regulator;
+ }
+
+ error = input_register_device(haptic->input_dev);
+ if (error) {
+ dev_err(&pdev->dev,
+ "couldn't register input device: %d\n",
+ error);
+ goto err_destroy_ff;
+ }
+
+ platform_set_drvdata(pdev, haptic);
+
+ return 0;
+
+err_destroy_ff:
+ input_ff_destroy(haptic->input_dev);
+err_put_regulator:
+ regulator_put(haptic->regulator);
+err_ifree_mem:
+ input_free_device(haptic->input_dev);
+err_kfree_mem:
+ kfree(haptic);
+
+ return error;
+}
+
+static int regulator_haptic_remove(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
+
+ input_unregister_device(haptic->input_dev);
+
+ return 0;
+}
+
+static struct of_device_id regulator_haptic_dt_match[] = {
+ { .compatible = "linux,regulator-haptic" },
+ {},
+};
+
+static struct platform_driver regulator_haptic_driver = {
+ .driver = {
+ .name = "regulator-haptic",
+ .owner = THIS_MODULE,
+ .of_match_table = regulator_haptic_dt_match,
+ },
+
+ .probe = regulator_haptic_probe,
+ .remove = regulator_haptic_remove,
+};
+module_platform_driver(regulator_haptic_driver);
+
+MODULE_ALIAS("platform:regulator-haptic");
+MODULE_DESCRIPTION("Regulator haptic driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Hyunhee Kim <hyunhee.kim@samsung.com>");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)
From: Florian Echtler @ 2013-10-11 9:22 UTC (permalink / raw)
To: David Herrmann, HID CORE LAYER
Cc: Henrik Rydberg, Benjamin Tissoires, Dmitry Torokhov
In-Reply-To: <CANq1E4R5-WEx_e1vYOmY-xGL0w669Qj54SGLU_tb8h97=5zH=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
On 02.10.2013 15:59, David Herrmann wrote:
>>> Or maybe even replace it by "u32 angle;". That should always be safe.
>>> Once you make use of this field, you can reconsider whether it's worth
>>> doing FP in the kernel. But as long as it's unused, I'd vote for
>>> avoiding "float" entirely.
>>
>> I was indeed planning to use this for orientation (as intended) in the
>> next iteration, what macros would I have to use for proper float handling?
>
> Archived from 2003 but afaik his last paragraph still applies today:
> http://yarchive.net/comp/linux/kernel_fp.html
>
> So what you should do is forward the raw angle data to user-space and
> let them deal with it. We usually don't apply policy in the kernel but
> instead forward the given data to the user and let them do the
> orientation computations. Any specific reason why you want to do that
> in the kernel?
I think it would be more consistent to have an EV_ABS value for
orientation, ranging e.g. from 0 to 359 (or rather from 0 to e.g. 90, as
described in multi-touch-protocol.txt). For pass-through to work, I
would probably have to set min and max to 0 and __UINT32_MAX__?
Alternatively, I think it should be possible to perform the required
conversion using integer arithmetic and bit operations alone.
However, for the time being, I'd suggest to simply leave the float
alone, use just a 0/1 value for orientation and deal with this in a
later patch, agreed?
One additional question: is there any provision in the multitouch
protocol for differentiation between various types of objects, e.g.
"finger" and "palm"?
BTW, what's the best practice for resubmitting a patch? I've used "git
commit --amend" on my previous commit, and would now just use "git
send-email" again, creating a new thread?
Best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [RFC] usbtouchscreen: stuck BTN_TOUCH release events
From: Christian Engelmayer @ 2013-10-11 11:42 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-usb, christian.engelmayer
Hello,
We are using the usbtouchscreen driver for a 0eef:0001 eGalax based device and
have observed cases were BTN_TOUCH seems to be stuck as release events are not
reported promptly. In those situations the release event is reported after
arbitrary time when the next touch event is triggered.
An usbmon trace shows that the problem occurs reproducible when the final 5
byte report containing the liftoff event finishes at an 8 byte boundary:
ceb81c80 1241543630 C Ii:1:002:1 0:4 16 = 81097c0a 5b81097c 0a5a8109 7b0a5a81
ceb81c80 1241543964 S Ii:1:002:1 -115:4 16 <
ceb81c80 1241555630 C Ii:1:002:1 0:4 16 = 097a0a5a 8109780a 59810975 0a578109
ceb81c80 1241555988 S Ii:1:002:1 -115:4 16 <
---[abort - urb gets unlinked]---
ceb81c80 1250629867 C Ii:1:002:1 -2:4 8 = 730a5380 09730a53
The usbtouchscreen driver is aware of both the report and diagnostic packets
supported by the controller. It enables multi frame support and defines the
report size for the eGalax to the 16 byte maximum diagnostic packet size
opposed to the 5 byte coordinate report.
In my opinion the situation described above is caused because the same size
definition is used for buffer allocation and interrupt endpoint requests to
the USB subsystem. The ehci-hcd will split the 16 byte request into up to 2
accesses according to the wMaxPacketSize of 8 byte for this endpoint. In case
the first transfer is answered by the eGalax with not less than the full 8 byte
requested, the host controller has got no way of knowing that the touch
controller will not have additional queued data until the next touch event.
As I am normally not involved into input drivers, please give me a hint to a
solution to this issue that would be acceptable for the maintainers and I can
prepare a tested patch accordingly.
Regards,
Christian
---
Bus 001 Device 002: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0eef D-WAV Scientific Co., Ltd
idProduct 0x0001 eGalax TouchScreen
bcdDevice 1.00
iManufacturer 1 eGalax Inc.
iProduct 2 USB TouchController
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB TouchScreen
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 5
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.04
iManufacturer 3 Linux 3.4.61-rel_4_4002_0-svn216359 ehci_hcd
iProduct 2 Freescale On-Chip EHCI Host Controller
iSerial 1 fsl-ehci.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0303 lowspeed power enable connect
Device Status: 0x0001
Self Powered
^ permalink raw reply
* [PATCH 1/1][Resend] Input: cypress_ps2 - Return zero finger count if palm is detected.
From: Joseph Salisbury @ 2013-10-11 16:30 UTC (permalink / raw)
To: dmitry.torokhov, rydberg
Cc: Kamal Mostafa, linux-kernel, dudl, git, tim.gardner, linux-input
In-Reply-To: <1380571922.15513.29.camel@fourier>
On 09/30/2013 04:12 PM, Kamal Mostafa wrote:
> On Tue, 2013-09-24 at 11:44 -0400, Joseph Salisbury wrote:
>> BugLink: http://bugs.launchpad.net/bugs/1229361
>>
>> This patch sets the finger count to 0 in the case of palm contact.
>>
>> Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT (KEYBOARD,...,commit_signer:2/2=100%)
>> Cc: Henrik Rydberg <rydberg@euromail.se> (maintainer:INPUT MULTITOUCH...)
>> Cc: Kamal Mostafa <kamal@canonical.com> (commit_signer:2/2=100%)
>> Cc: Dudley Du <dudl@cypress.com> (commit_signer:2/2=100%)
>> Cc: Kyle Fazzari <git@status.e4ward.com> (commit_signer:1/2=50%)
>> Cc: Tim Gardner <tim.gardner@canonical.com> (commit_signer:1/2=50%)
>> Cc: linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
>> Cc: linux-kernel@vger.kernel.org (open list)
>> Cc: stable@vger.kernel.org
> This patch works fine: eliminates stream of junk driver messages with no
> ill effects.
>
> Tested-by: Kamal Mostafa <kamal@canonical.com>
>
> -Kamal
>
>
>> ---
>> drivers/input/mouse/cypress_ps2.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/mouse/cypress_ps2.c b/drivers/input/mouse/cypress_ps2.c
>> index 45b3eda..95b2c40 100644
>> --- a/drivers/input/mouse/cypress_ps2.c
>> +++ b/drivers/input/mouse/cypress_ps2.c
>> @@ -441,7 +441,7 @@ static int cypress_get_finger_count(unsigned char header_byte)
>> case 2: return 5;
>> default:
>> /* Invalid contact (e.g. palm). Ignore it. */
>> - return -1;
>> + return 0;
>> }
>> }
>>
>> @@ -460,7 +460,7 @@ static int cypress_parse_packet(struct psmouse *psmouse,
>>
>> contact_cnt = cypress_get_finger_count(header_byte);
>>
>> - if (contact_cnt < 0) /* e.g. palm detect */
>> + if (contact_cnt < 0)
>> return -EINVAL;
>>
>> report_data->contact_cnt = contact_cnt;
Hi Dmitry and Henrik,
Have you had a chance to review this patch to consider it for inclusion
in mainline?
Thanks,
Joe
^ permalink raw reply
* Disabling the tsc2005 driver at runtime
From: Phil Carmody @ 2013-10-11 16:38 UTC (permalink / raw)
To: dmitry.torokhov
Cc: freemangordon, linux-input, wfp5p, broonie, linux-kernel, pc+n900
Greetings, Dmitry,
I'm looking for some advice regarding locally restoring a feature into
the tsc2005 driver that was removed back in:
http://www.spinics.net/lists/linux-input/msg14575.html
commit 5cb81d1: Input: tsc2005 - remove 'disable' sysfs attribute
Given the prior patch in the patchset:
commit 0b950d3: Input: tsc2005 - add open/close
"Introduce open and close methods for the input device
to keep the device powered down when it is not in use."
it seems you were expecting the device node to only have one reader, and
that reader would be the entity who decided when it was time to disable
and power down the device.
However, in the Nokia N900, the device node has at least 3 readers, 2 of
which I believe are closed source components, and therefore cannot be
modified to follow kernel changes. And even then, forcing 3 userspace
programs to now have to actively participate in the disabling of the
device seems excessively wasteful, compared with the ultimate simplicity
of the clients not even having to know about such things, which is how
it was before the change.
Back then you mentioned a generic interface that should replace this
device-specific one, but I can see no documentation for such an
interface in the kernel Documentation/ABI. Can you elaborate?
At the moment, as we can't break userspace, it seems that if we want to
run a more modern kernel on the N900 or another tsc2005-based device
running Fremantle, we should just locally revert that patch, and take
the maintenance hit ourselves for the implications of that. (Here 'we'
= the volunteer community still supporting the device because of its
longevity.)
Cheers,
Phil
--
People generally seem to want software to be free as in speech and/or
free as in beer. Unfortunately rather too much of it is free as in jazz.
-- Janet McKnight, on a private newsgroup
^ permalink raw reply
* Re: [PATCH 1/2] Input: twl4030_keypad - add device tree support
From: Tony Lindgren @ 2013-10-11 23:38 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, linux-input, 'Benoît Cousson',
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Russell King, Dmitry Torokhov,
Grant Likely, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, linux-omap
In-Reply-To: <1381353447-32708-1-git-send-email-sre@debian.org>
* Sebastian Reichel <sre@debian.org> [131009 14:25]:
> Add device tree support for twl4030 keypad driver and update the
> Documentation with twl4030 keypad device tree binding information.
>
> This patch also adds a twl4030 keypad node to the twl4030.dtsi file,
> so that board files can just add the keymap.
>
> Tested on Nokia N900.
Nice :) Just few cosmetic comments below.
>
> +#ifdef CONFIG_OF
> +static int twl4030_keypad_parse_dt(struct device *dev,
> + struct twl4030_keypad *keypad_data)
> +{
I guess the way to go nowadays is to use #IS_ENABLED(CONFIG_OF) here
and later on in this patch.
> @@ -331,20 +358,12 @@ static int twl4030_kp_program(struct twl4030_keypad *kp)
> static int twl4030_kp_probe(struct platform_device *pdev)
> {
> struct twl4030_keypad_data *pdata = pdev->dev.platform_data;
> - const struct matrix_keymap_data *keymap_data;
> + const struct matrix_keymap_data *keymap_data = NULL;
> struct twl4030_keypad *kp;
> struct input_dev *input;
> u8 reg;
> int error;
>
> - if (!pdata || !pdata->rows || !pdata->cols || !pdata->keymap_data ||
> - pdata->rows > TWL4030_MAX_ROWS || pdata->cols > TWL4030_MAX_COLS) {
> - dev_err(&pdev->dev, "Invalid platform_data\n");
> - return -EINVAL;
> - }
> -
> - keymap_data = pdata->keymap_data;
> -
> kp = kzalloc(sizeof(*kp), GFP_KERNEL);
> input = input_allocate_device();
> if (!kp || !input) {
I assume you have tested the above so it does not break things
for legacy booting?
Other than that:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: N900: TWL4030 Keypad Matrix definition
From: Tony Lindgren @ 2013-10-11 23:39 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, linux-input, 'Benoît Cousson',
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Russell King, Dmitry Torokhov,
Grant Likely, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, linux-omap
In-Reply-To: <1381353447-32708-2-git-send-email-sre@debian.org>
* Sebastian Reichel <sre@debian.org> [131009 14:26]:
> Add Keyboard Matrix information to N900's DTS file.
> This patch maps the keys exactly as the original
> board code.
This should be queued by Benoit along with other .dts
changes, not via the input tree:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] Input: nspire-keypad - add missing clk_disable_unprepare() on error path
From: Wei Yongjun @ 2013-10-12 6:32 UTC (permalink / raw)
To: dmitry.torokhov, grant.likely, rob.herring, dt.tangr, yongjun_wei,
Julia.Lawall, viresh.kumar
Cc: linux-input
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add the missing clk_disable_unprepare() before return
from nspire_keypad_open() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/input/keyboard/nspire-keypad.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/nspire-keypad.c b/drivers/input/keyboard/nspire-keypad.c
index b3e3eda..85e8d80 100644
--- a/drivers/input/keyboard/nspire-keypad.c
+++ b/drivers/input/keyboard/nspire-keypad.c
@@ -143,8 +143,10 @@ static int nspire_keypad_open(struct input_dev *input)
return error;
error = nspire_keypad_chip_init(keypad);
- if (error)
+ if (error) {
+ clk_disable_unprepare(keypad->clk);
return error;
+ }
return 0;
}
^ permalink raw reply related
* Re: [PATCH v2 1/2] Input: rotary-encoder: Add 'stepped' irq handler
From: Ezequiel García @ 2013-10-12 16:58 UTC (permalink / raw)
To: Daniel Mack; +Cc: linux-kernel@vger.kernel.org, linux-input, Dmitry Torokhov
In-Reply-To: <524EC022.2050203@gmail.com>
Dmitry,
On 4 October 2013 10:18, Daniel Mack <zonque@gmail.com> wrote:
> On 04.10.2013 14:53, Ezequiel Garcia wrote:
>> Some rotary-encoder devices (such as those with detents) are capable
>> of producing a stable event on each step. This commit adds support
>> for this case, by implementing a new interruption handler.
>>
>> The handler needs only detect the direction of the turn and generate
>> an event according to this detection.
>
> I think you can squash patch 2/2 into this one. It doesn't make much
> sense to have a one-liner patch to just update the documenation separately.
>
> Other than that, the code looks fine to me.
>
> Acked-by: Daniel Mack <zonque@gmail.com>
>
Could you merge these two patches?
It's already acked by Daniel, and there wasn't any other feedback
so I think we're ready to get them in and support more devices :-)
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* joydev: Keyboards incorrectly identified as joystick
From: Jethro Beekman @ 2013-10-12 22:05 UTC (permalink / raw)
To: linux-input
Or, really: "Keyboards incorrectly say they're a joystick". Some keyboard like
to say they have joystick capabilities while they don't. This results in a
joystick device showing up (e.g. in games) that is not calibrated and just
generally messes things up.
This seems to happen with multiple keyboards, mostly from Microsoft: e.g. the
Microsoft Digital Media Pro Keyboard and Microsoft Wired Keyboard 600.
Earlier reports on this mailing list:
http://thread.gmane.org/gmane.linux.kernel.input/25913
http://thread.gmane.org/gmane.linux.kernel.input/25926
Downstream bug reports:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987877
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959
evtest output for certain keyboards:
https://launchpadlibrarian.net/112444244/evtest2
http://pastebin.com/tX4nnhAg
It would be easy to add an exception to joydev_match() like there currently are
for touchpads, tablets, etc. The question is: what should the test be? Or should
this be handled in userspace (udev)?
Jethro Beekman
^ permalink raw reply
* Problem with Mighty Mouse
From: Bastien Nocera @ 2013-10-12 23:48 UTC (permalink / raw)
To: linux-input
Heya,
I've tested a Bluetooth Apple Mighty Mouse (AA1197) and though I can
move the cursor without a problem, none of the buttons work. evtest
doesn't see any button events.
Any ideas what I should look at, or which tool I could use to capture
the raw data?
Cheers
^ permalink raw reply
* [PATCH 1/1] HID: Fix unit exponent parsing again
From: Nikolai Kondrashov @ 2013-10-13 12:09 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, Benjamin Tissoires, Nikolai Kondrashov
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
---
drivers/hid/hid-core.c | 11 ++++++-----
drivers/hid/hid-input.c | 13 ++++---------
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b8470b1..013cad0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -319,7 +319,7 @@ static s32 item_sdata(struct hid_item *item)
static int hid_parser_global(struct hid_parser *parser, struct hid_item *item)
{
- __u32 raw_value;
+ __s32 raw_value;
switch (item->tag) {
case HID_GLOBAL_ITEM_TAG_PUSH:
@@ -370,10 +370,11 @@ static int hid_parser_global(struct hid_parser *parser, struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_UNIT_EXPONENT:
- /* Units exponent negative numbers are given through a
- * two's complement.
- * See "6.2.2.7 Global Items" for more information. */
- raw_value = item_udata(item);
+ /* Many devices provide unit exponent as a two's complement
+ * nibble due to the common misunderstanding of HID
+ * specification 1.11, 6.2.2.7 Global Items. Attempt to handle
+ * both this and the standard encoding. */
+ raw_value = item_sdata(item);
if (!(raw_value & 0xfffffff0))
parser->global.unit_exponent = hid_snto32(raw_value, 4);
else
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 8741d95..d97f232 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -192,6 +192,7 @@ static int hidinput_setkeycode(struct input_dev *dev,
return -EINVAL;
}
+
/**
* hidinput_calc_abs_res - calculate an absolute axis resolution
* @field: the HID report field to calculate resolution for
@@ -234,23 +235,17 @@ __s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
case ABS_MT_TOOL_Y:
case ABS_MT_TOUCH_MAJOR:
case ABS_MT_TOUCH_MINOR:
- if (field->unit & 0xffffff00) /* Not a length */
- return 0;
- unit_exponent += hid_snto32(field->unit >> 4, 4) - 1;
- switch (field->unit & 0xf) {
- case 0x1: /* If centimeters */
+ if (field->unit == 0x11) { /* If centimeters */
/* Convert to millimeters */
unit_exponent += 1;
- break;
- case 0x3: /* If inches */
+ } else if (field->unit == 0x13) { /* If inches */
/* Convert to millimeters */
prev = physical_extents;
physical_extents *= 254;
if (physical_extents < prev)
return 0;
unit_exponent -= 1;
- break;
- default:
+ } else {
return 0;
}
break;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH v2 1/2] Add an additional argument for decode routine, change secondary device name
From: Kevin Cernekee @ 2013-10-13 16:23 UTC (permalink / raw)
To: Yunkang Tang; +Cc: Dmitry Torokhov, yunkang.tang, linux-input, david turvene
In-Reply-To: <1379045010-3347-2-git-send-email-yunkang.tang@cn.alps.com>
> [PATCH v2 2/2] Improve the performance of alps v5-protocol's touchpad
>
> From: Yunkang Tang <yunkang.tang@xxxxxxxxxxx>
>
> - Calculate the device's dimension in alps_identify().
> - Change the logic of packet decoding.
> - Add the new data process logic.
>
> Signed-off-by: Yunkang Tang <yunkang.tang@xxxxxxxxxxx>
Hmm, somehow the [2/2] patch made it into the linux-input list
archives, but linux-input did not forward it to my inbox so I missed
it the first time around.
But thanks for sending these changes. There has been a great deal of
interest in enhancing ALPS touchpad support, especially for the
Dolphin models.
Some review comments follow:
> ---
> drivers/input/mouse/alps.c | 278 ++++++++++++++++++++++++++++++++++++++++++---
> drivers/input/mouse/alps.h | 4 +
> 2 files changed, 264 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 7e8a4fb..86c956a 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -257,6 +257,75 @@ static void alps_process_packet_v1_v2(struct psmouse *psmouse)
> }
>
> /*
> + * Process bitmap data for V5 protocols. Return value is null.
> + *
> + * The bitmaps don't have enough data to track fingers, so this function
> + * only generates points representing a bounding box of at most two contacts.
> + * These two points are returned in x1, y1, x2, and y2.
> + */
> +static void alps_process_bitmap_dolphin(struct alps_data *priv,
> + struct alps_fields *fields,
> + int *x1, int *y1, int *x2, int *y2)
> +{
> + struct alps_palm_bitmap {
> + int start_bit;
> + int end_bit;
> + };
> +
> + int i;
> + int box_middle_x, box_middle_y;
> + unsigned int x_map, y_map;
> + struct alps_palm_bitmap x_bitmap = {0}, y_bitmap = {0};
> +
> + x_map = fields->x_map;
> + y_map = fields->y_map;
> +
> + if (!x_map || !y_map)
> + return;
> +
> + *x1 = *y1 = *x2 = *y2 = 0;
> +
> + if (fields->fingers > 1) {
> + for (i = 0; i < 32; i++) {
Extra space after "i = 0;"
> + if (x_map & (1 << i)) {
> + x_bitmap.end_bit = priv->x_bits - i;
> + break;
> + }
> + }
> +
> + for (i = 31; i >= 0; i--) {
> + if (x_map & (1 << i)) {
> + x_bitmap.start_bit = priv->x_bits - i;
> + break;
> + }
> + }
> +
> + for (i = 0; i < 32; i++) {
Same here
> + if (y_map & (1 << i)) {
> + y_bitmap.start_bit = i;
> + break;
> + }
> + }
So, assuming x_bits == y_bits == 8, and both x_map and y_map are in
the range 0x00..0xff:
y_bitmap.* lies in the range 0..7
x_bitmap.* lies in the range 1..8
Is that correct, or is x_bitmap off by one?
> + for (i = 31; i >= 0; i--) {
> + if (y_map & (1 << i)) {
> + y_bitmap.end_bit = i;
> + break;
> + }
> + }
I suspect that this whole function could be simplified a bit.
Would it be possible to use ffs() and fls() instead of loops?
Just a personal preference, but if you calculated X first and then Y,
it may require fewer temporary variables and the alps_palm_bitmap
struct could be removed.
> +
> + box_middle_x = (priv->x_max * (x_bitmap.start_bit + x_bitmap.end_bit)) /
> + (2 * (priv->x_bits - 1));
> + box_middle_y = (priv->y_max * (y_bitmap.start_bit + y_bitmap.end_bit)) /
> + (2 * (priv->y_bits - 1));
These lines look a bit long - suggest running through checkpatch.pl
I assume start_bit and end_bit can never be negative, because the code
that calculates e.g. x_map will populate at most bits 0..(x_bits-1)?
> + *x1 = fields->x;
> + *y1 = fields->y;
> + *x2 = 2 * box_middle_x - *x1;
> + *y2 = 2 * box_middle_y - *y1;
> + }
> +}
> +
> +/*
> * Process bitmap data from v3 and v4 protocols. Returns the number of
> * fingers detected. A return value of 0 means at least one of the
> * bitmaps was empty.
> @@ -495,25 +564,55 @@ static void alps_decode_rushmore(struct alps_fields *f, unsigned char *p,
> static void alps_decode_dolphin(struct alps_fields *f, unsigned char *p,
> struct psmouse *psmouse)
> {
> + unsigned int palm_high = 0, palm_low = 0, palm_mask = 0;
> + int i, remain_xbits;
> + struct alps_data *priv = psmouse->private;
> +
> f->first_mp = !!(p[0] & 0x02);
> f->is_mp = !!(p[0] & 0x20);
>
> - f->fingers = ((p[0] & 0x6) >> 1 |
> + if (!f->is_mp) {
> + f->x = ((p[1] & 0x7f) | ((p[4] & 0x0f) << 7));
> + f->y = ((p[2] & 0x7f) | ((p[4] & 0xf0) << 3));
> + f->z = (p[0] & 4) ? 0 : p[5] & 0x7f;
> + alps_decode_buttons_v3(f, p);
> + } else {
> + f->fingers = ((p[0] & 0x6) >> 1 |
> (p[0] & 0x10) >> 2);
> - f->x_map = ((p[2] & 0x60) >> 5) |
> - ((p[4] & 0x7f) << 2) |
> - ((p[5] & 0x7f) << 9) |
> - ((p[3] & 0x07) << 16) |
> - ((p[3] & 0x70) << 15) |
> - ((p[0] & 0x01) << 22);
> - f->y_map = (p[1] & 0x7f) |
> - ((p[2] & 0x1f) << 7);
> -
> - f->x = ((p[1] & 0x7f) | ((p[4] & 0x0f) << 7));
> - f->y = ((p[2] & 0x7f) | ((p[4] & 0xf0) << 3));
> - f->z = (p[0] & 4) ? 0 : p[5] & 0x7f;
>
> - alps_decode_buttons_v3(f, p);
> + palm_low = (p[1] & 0x7f) |
> + ((p[2] & 0x7f) << 7) |
> + ((p[4] & 0x7f) << 14) |
> + ((p[5] & 0x7f) << 21) |
> + ((p[3] & 0x07) << 28) | ((p[3] & 0x10) << 27);
> + palm_high = ((p[3] & 0x60) >> 5) | ((p[0] & 0x01) << 2);
> +
> + for (i = 0; i < priv->y_bits; i++)
> + palm_mask |= 1 << i;
> +
> + /* Y-profile is stored in P(0) to p(n), n = y_bits; */
> + f->y_map = palm_low & palm_mask;
Suggest something like:
f->y_map = palm_low & (BIT(priv->y_bits) - 1);
> +
> + /* X-profile is stored in p(n) to p(n+x_bits). */
> + palm_mask = 0;
> + for (i = priv->y_bits; i < 32 && i < priv->y_bits + priv->x_bits; i++)
> + palm_mask |= 1 << i;
> +
> + f->x_map = ((palm_low & (palm_mask)) >> priv->y_bits);
Likewise, maybe use:
f->x_map = (palm_low >> priv->y_bits) & (BIT(priv->x_bits) - 1);
(but double-check my math first)
> +
> + /*
> + * In some cases, palm_low's 32bit is not enough to save
> + * all X&Y-profiles, we need to use palm_high.
> + */
> + remain_xbits = priv->x_bits + priv->y_bits - 32;
> + if (remain_xbits > 0) {
> + palm_mask = 0;
> + for (i = 0; i < remain_xbits; i++)
> + palm_mask |= 1 << i;
> +
> + f->x_map |= ((palm_high & palm_mask) << (32 - priv->y_bits));
Would it be cleaner to just use a u64 for the palm data, instead of
splitting into low/high? (If so you'll probably want to compile-test
a 32-bit kernel.)
> + }
> + }
> }
>
> static void alps_process_touchpad_packet_v3(struct psmouse *psmouse)
> @@ -745,6 +844,112 @@ static void alps_process_packet_v4(struct psmouse *psmouse)
> input_sync(dev);
> }
>
> +
> +static void alps_process_touchpad_packet_v5(struct psmouse *psmouse)
> +{
> + struct alps_data *priv = psmouse->private;
> + unsigned char *packet = psmouse->packet;
> + struct input_dev *dev = psmouse->dev;
> + int x1 = 0, y1 = 0, x2 = 0, y2 = 0;
> + int fingers = 0;
> + struct alps_fields f;
> +
> + priv->decode_fields(&f, packet, psmouse);
> +
> + /*
> + * There's no single feature of touchpad position and bitmap packets
> + * that can be used to distinguish between them. We rely on the fact
> + * that a bitmap packet should always follow a position packet with
> + * bit 6 of packet[4] set.
> + */
> + if (priv->multi_packet) {
> + /*
> + * Sometimes a position packet will indicate a multi-packet
> + * sequence, but then what follows is another position
> + * packet. Check for this, and when it happens process the
> + * position packet as usual.
> + */
> + if (f.is_mp) {
> + fingers = f.fingers;
> + priv->decode_fields(&f, priv->multi_data, psmouse);
> + alps_process_bitmap_dolphin(priv, &f, &x1, &y1,
> + &x2, &y2);
Aside from this clause, alps_process_touchpad_packet_v5() is virtually
identical to alps_process_touchpad_packet_v3(). It would be good to
find a way to reuse more of the code.
> + } else {
> + priv->multi_packet = 0;
> + }
> + }
> +
> + /*
> + * Bit 6 of byte 0 is not usually set in position packets. The only
> + * times it seems to be set is in situations where the data is
> + * suspect anyway, e.g. a palm resting flat on the touchpad. Given
> + * this combined with the fact that this bit is useful for filtering
> + * out misidentified bitmap packets, we reject anything with this
> + * bit set.
> + */
> + if (f.is_mp)
> + return;
> +
> + if (!priv->multi_packet && f.first_mp) {
> + priv->multi_packet = 1;
> + memcpy(priv->multi_data, packet, sizeof(priv->multi_data));
> + return;
> + }
> +
> + priv->multi_packet = 0;
> +
> + /*
> + * Sometimes the hardware sends a single packet with z = 0
> + * in the middle of a stream. Real releases generate packets
> + * with x, y, and z all zero, so these seem to be flukes.
> + * Ignore them.
> + */
> + if (f.x && f.y && !f.z)
> + return;
> +
> + /*
> + * If we don't have MT data or the bitmaps were empty, we have
> + * to rely on ST data.
> + */
> + if (!fingers) {
> + x1 = f.x;
> + y1 = f.y;
> + fingers = f.z > 0 ? 1 : 0;
> + }
> +
> + if (f.z >= 64)
> + input_report_key(dev, BTN_TOUCH, 1);
> + else
> + input_report_key(dev, BTN_TOUCH, 0);
> +
> + alps_report_semi_mt_data(dev, fingers, x1, y1, x2, y2);
> +
> + input_mt_report_finger_count(dev, fingers);
> +
> + input_report_key(dev, BTN_LEFT, f.left);
> + input_report_key(dev, BTN_RIGHT, f.right);
> + input_report_key(dev, BTN_MIDDLE, f.middle);
> +
> + if (f.z > 0) {
> + input_report_abs(dev, ABS_X, f.x);
> + input_report_abs(dev, ABS_Y, f.y);
> + }
> + input_report_abs(dev, ABS_PRESSURE, f.z);
> +
> + input_sync(dev);
> +}
> +
> +static void alps_process_packet_v5(struct psmouse *psmouse)
> +{
> + unsigned char *packet = psmouse->packet;
> +
> + /* Ignore stick point data */
> + if (packet[0] == 0xD8)
> + return;
> +
> + alps_process_touchpad_packet_v5(psmouse);
> +}
> +
> static void alps_report_bare_ps2_packet(struct psmouse *psmouse,
> unsigned char packet[],
> bool report_buttons)
> @@ -1522,6 +1727,41 @@ error:
> return -1;
> }
>
> +static int alps_dolphin_get_device_area(struct psmouse *psmouse,
> + struct alps_data *priv)
> +{
> + struct ps2dev *ps2dev = &psmouse->ps2dev;
> + unsigned char param[4] = {0};
> + int num_x_electrode, num_y_electrode;
> +
> + if (alps_enter_command_mode(psmouse))
> + return -1;
> +
> + if (ps2_command(ps2dev, NULL, 0x00EC) ||
> + ps2_command(ps2dev, NULL, 0x00F0) ||
> + ps2_command(ps2dev, NULL, 0x00F0) ||
> + ps2_command(ps2dev, NULL, 0x00F3) ||
> + ps2_command(ps2dev, NULL, 0x000A) ||
> + ps2_command(ps2dev, NULL, 0x00F3) ||
> + ps2_command(ps2dev, NULL, 0x000A))
> + return -1;
> +
> + if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO))
> + return -1;
> +
> + num_x_electrode = DOLPHIN_PROFILE_XOFFSET + (param[2] & 0x0F);
> + num_y_electrode = DOLPHIN_PROFILE_YOFFSET + ((param[2] >> 4) & 0x0F);
This is strictly optional, but adding a comment indicating typical
values for num_x_electrode and num_y_electrode could aid in
understanding the math.
> + priv->x_bits = num_x_electrode;
> + priv->y_bits = num_y_electrode;
> + priv->x_max = (num_x_electrode - 1) * DOLPHIN_COUNT_PER_ELECTRODE;
> + priv->y_max = (num_y_electrode - 1) * DOLPHIN_COUNT_PER_ELECTRODE;
> +
> + if (alps_exit_command_mode(psmouse))
> + return -1;
> +
> + return 0;
> +}
> +
> static int alps_hw_init_dolphin_v1(struct psmouse *psmouse)
> {
> struct ps2dev *ps2dev = &psmouse->ps2dev;
> @@ -1574,7 +1814,7 @@ static void alps_set_defaults(struct alps_data *priv)
> break;
> case ALPS_PROTO_V5:
> priv->hw_init = alps_hw_init_dolphin_v1;
> - priv->process_packet = alps_process_packet_v3;
> + priv->process_packet = alps_process_packet_v5;
> priv->decode_fields = alps_decode_dolphin;
> priv->set_abs_params = alps_set_abs_params_mt;
> priv->nibble_commands = alps_v3_nibble_commands;
> @@ -1648,11 +1888,13 @@ static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
> if (alps_match_table(psmouse, priv, e7, ec) == 0) {
> return 0;
> } else if (e7[0] == 0x73 && e7[1] == 0x03 && e7[2] == 0x50 &&
> - ec[0] == 0x73 && ec[1] == 0x01) {
> + ec[0] == 0x73 && (ec[1] == 0x01 || ec[1] == 0x02)) {
> priv->proto_version = ALPS_PROTO_V5;
> alps_set_defaults(priv);
> -
> - return 0;
> + if (alps_dolphin_get_device_area(psmouse, priv))
> + return -EIO;
> + else
> + return 0;
> } else if (ec[0] == 0x88 && ec[1] == 0x08) {
> priv->proto_version = ALPS_PROTO_V3;
> alps_set_defaults(priv);
> diff --git a/drivers/input/mouse/alps.h b/drivers/input/mouse/alps.h
> index cdc10f3..43d89fc7 100644
> --- a/drivers/input/mouse/alps.h
> +++ b/drivers/input/mouse/alps.h
> @@ -18,6 +18,10 @@
> #define ALPS_PROTO_V4 4
> #define ALPS_PROTO_V5 5
>
> +#define DOLPHIN_COUNT_PER_ELECTRODE 64
> +#define DOLPHIN_PROFILE_XOFFSET 8 /* x-electrode offset */
> +#define DOLPHIN_PROFILE_YOFFSET 1 /* y-electrode offset */
> +
> /**
> * struct alps_model_info - touchpad ID table
> * @signature: E7 response string to match.
^ permalink raw reply
* [PATCH] Input: wacom - Export battery scope
From: Bastien Nocera @ 2013-10-13 19:49 UTC (permalink / raw)
To: linux-input; +Cc: dmitry.torokhov, peter.hutterer, chris, killertofu
This will stop UPower from detecting the tablet as a power supply,
and using its battery status to hibernate or switch off the machine.
https://bugs.freedesktop.org/show_bug.cgi?id=70321
Signed-off-by: Bastien Nocera <hadess@hadess.net>
---
drivers/input/tablet/wacom_sys.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 79b69ea..e53416a 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -1031,6 +1031,7 @@ static void wacom_destroy_leds(struct wacom *wacom)
}
static enum power_supply_property wacom_battery_props[] = {
+ POWER_SUPPLY_PROP_SCOPE,
POWER_SUPPLY_PROP_CAPACITY
};
@@ -1042,6 +1043,9 @@ static int wacom_battery_get_property(struct power_supply *psy,
int ret = 0;
switch (psp) {
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_DEVICE;
+ break;
case POWER_SUPPLY_PROP_CAPACITY:
val->intval =
wacom->wacom_wac.battery_capacity * 100 / 31;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] Input: wacom - add support for three new Intuos devices
From: Peter Hutterer @ 2013-10-14 0:27 UTC (permalink / raw)
To: Ping Cheng; +Cc: linux-input, dmitry.torokhov, chris, Ping Cheng
In-Reply-To: <1381439866-1161-1-git-send-email-pingc@wacom.com>
On Thu, Oct 10, 2013 at 02:17:46PM -0700, Ping Cheng wrote:
> This series of models added a hardware switch to turn touch
> data on/off. To report the state of the switch, SW_TOUCH
> is added in include/uapi/linux/input.h.
>
> The driver is also updated to process wireless devices that do
> not support touch interface.
>
> Tested-by: Jason Gerecke <killertofu@gmail.com>
> Signed-off-by: Ping Cheng <pingc@wacom.com>
> ---
> v2: Change SW_TOUCH_ENABLED to SW_TOUCH and clear BTN_TOUCH bit
> for button only interfaces as suggested by Peter Hutterer.
> ---
> drivers/input/tablet/wacom_sys.c | 16 +++++++-
> drivers/input/tablet/wacom_wac.c | 87 ++++++++++++++++++++++++++++++++--------
> drivers/input/tablet/wacom_wac.h | 7 ++++
> include/uapi/linux/input.h | 1 +
> 4 files changed, 93 insertions(+), 18 deletions(-)
>
[...]
> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
> index fd23a37..ba9e335 100644
> --- a/drivers/input/tablet/wacom_wac.h
> +++ b/drivers/input/tablet/wacom_wac.h
> @@ -54,6 +54,8 @@
> #define WACOM_REPORT_TPCST 16
> #define WACOM_REPORT_TPC1FGE 18
> #define WACOM_REPORT_24HDT 1
> +#define WACOM_REPORT_WL_MODE 128
> +#define WACOM_REPORT_USB_MODE 192
>
> /* device quirks */
> #define WACOM_QUIRK_MULTI_INPUT 0x0001
> @@ -81,6 +83,7 @@ enum {
> INTUOSPS,
> INTUOSPM,
> INTUOSPL,
> + INTUOS_HT,
nitpick: why the underscore? all other intuos enums are one word.
Cheers,
Peter
> WACOM_21UX2,
> WACOM_22HD,
> DTK,
^ permalink raw reply
* Re: [PATCH] input: qt1070: add power management ops
From: Bo Shen @ 2013-10-14 5:45 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: Nicolas Ferre, Wenyou.Yang, linux-arm-kernel, linux-input
In-Reply-To: <520B2921.3000906@atmel.com>
Hi Dmitry,
On 8/14/2013 14:52, Nicolas Ferre wrote:
> On 13/08/2013 09:43, Bo Shen :
>> Add power management ops for qt1070, it maybe a wakeup source
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Would this patch be applied with Nicolas' ACK?
Best Regards,
Bo Shen
>> ---
>> drivers/input/keyboard/qt1070.c | 25 +++++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/input/keyboard/qt1070.c
>> b/drivers/input/keyboard/qt1070.c
>> index 42b773b..deefe5a 100644
>> --- a/drivers/input/keyboard/qt1070.c
>> +++ b/drivers/input/keyboard/qt1070.c
>> @@ -243,6 +243,30 @@ static int qt1070_remove(struct i2c_client *client)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int qt1070_suspend(struct device *dev)
>> +{
>> + struct qt1070_data *data = dev_get_drvdata(dev);
>> +
>> + if (device_may_wakeup(dev))
>> + enable_irq_wake(data->irq);
>> +
>> + return 0;
>> +}
>> +
>> +static int qt1070_resume(struct device *dev)
>> +{
>> + struct qt1070_data *data = dev_get_drvdata(dev);
>> +
>> + if (device_may_wakeup(dev))
>> + disable_irq_wake(data->irq);
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(qt1070_pm_ops, qt1070_suspend, qt1070_resume);
>> +
>> static const struct i2c_device_id qt1070_id[] = {
>> { "qt1070", 0 },
>> { },
>> @@ -253,6 +277,7 @@ static struct i2c_driver qt1070_driver = {
>> .driver = {
>> .name = "qt1070",
>> .owner = THIS_MODULE,
>> + .pm = &qt1070_pm_ops,
>> },
>> .id_table = qt1070_id,
>> .probe = qt1070_probe,
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] Add an additional argument for decode routine, change secondary device name
From: Will Tommy @ 2013-10-14 5:50 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: Dmitry Torokhov, yunkang.tang, linux-input, david turvene
In-Reply-To: <CAJiQ=7D9ZBKJcGgYT+3se92t2zn6nzJ8645CzWdB2xh1S60+nQ@mail.gmail.com>
Hi Kevin,
Thanks for your carefully review. It's amazing !
> So, assuming x_bits == y_bits == 8, and both x_map and y_map are in
> the range 0x00..0xff:
>
> y_bitmap.* lies in the range 0..7
> x_bitmap.* lies in the range 1..8
>
> Is that correct, or is x_bitmap off by one?
Hmm, it seems a bug of algorithm. Both x_bitmay&y_bitmap's range should be 0..7.
I'll fix it.
> I suspect that this whole function could be simplified a bit.
>
> Would it be possible to use ffs() and fls() instead of loops?
>
> Just a personal preference, but if you calculated X first and then Y,
> it may require fewer temporary variables and the alps_palm_bitmap
> struct could be removed.
Thanks for your proposal. I'll re-write this function in next submission.
> > + box_middle_x = (priv->x_max * (x_bitmap.start_bit + x_bitmap.end_bit)) /
> > + (2 * (priv->x_bits - 1));
> > + box_middle_y = (priv->y_max * (y_bitmap.start_bit + y_bitmap.end_bit)) /
> > + (2 * (priv->y_bits - 1));
> These lines look a bit long - suggest running through checkpatch.pl
>
Yes, they're longer than 80. However, in order not to let code hard to
be understood,
I decided not to split them. Anyway, since this function would be
re-written, there
would be no problem.
> I assume start_bit and end_bit can never be negative, because the code
> that calculates e.g. x_map will populate at most bits 0..(x_bits-1)?
Do you mean it's not good to define start_bit & end_bit as "int" since they have
no chance to be negative ? Actually, "unsigned char" is much better.
> Suggest something like:
>
> f->y_map = palm_low & (BIT(priv->y_bits) - 1);
> Likewise, maybe use:
>
> f->x_map = (palm_low >> priv->y_bits) & (BIT(priv->x_bits) - 1);
>
> (but double-check my math first)
> Would it be cleaner to just use a u64 for the palm data, instead of
> splitting into low/high? (If so you'll probably want to compile-test
> a 32-bit kernel.)
> Aside from this clause, alps_process_touchpad_packet_v5() is virtually
> identical to alps_process_touchpad_packet_v3(). It would be good to
> find a way to reuse more of the code.
Okay, I'll take your advice and check the behavior on both 32-bit and 64-bit.
> This is strictly optional, but adding a comment indicating typical
> values for num_x_electrode and num_y_electrode could aid in
> understanding the math.
That's a good idea! I'll add them.
Tommy
^ permalink raw reply
* Re: [PATCH v2 1/2] Add an additional argument for decode routine, change secondary device name
From: Kevin Cernekee @ 2013-10-14 6:02 UTC (permalink / raw)
To: Will Tommy; +Cc: Dmitry Torokhov, yunkang.tang, linux-input, david turvene
In-Reply-To: <CA+F6ckOfK25hhCxcJ5JRbzt+o1BKYvOynB1DQkPY+RSZrp8KFw@mail.gmail.com>
On Sun, Oct 13, 2013 at 10:50 PM, Will Tommy <tommywill2011@gmail.com> wrote:
>> I assume start_bit and end_bit can never be negative, because the code
>> that calculates e.g. x_map will populate at most bits 0..(x_bits-1)?
>
> Do you mean it's not good to define start_bit & end_bit as "int" since they have
> no chance to be negative ? Actually, "unsigned char" is much better.
No type change needed - I was just checking to make sure it wasn't a
risk, since getting a negative number in there would really throw off
the math...
^ permalink raw reply
* Re: [PATCH v2 1/2] Add an additional argument for decode routine, change secondary device name
From: Tommy Will @ 2013-10-14 6:10 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: Dmitry Torokhov, yunkang.tang, linux-input, david turvene
In-Reply-To: <CAJiQ=7ChMZDEbUE_761NLwByWSCQTBM8ek=NQvVNQwjBN=SqBA@mail.gmail.com>
2013/10/14 Kevin Cernekee <cernekee@gmail.com>:
> On Sun, Oct 13, 2013 at 10:50 PM, Will Tommy <tommywill2011@gmail.com> wrote:
>
> No type change needed - I was just checking to make sure it wasn't a
> risk, since getting a negative number in there would really throw off
> the math...
Got that. Thanks : )
^ permalink raw reply
* WPC8769L (WEC1020) support in winbond-cir?
From: Tom Gundersen @ 2013-10-14 13:16 UTC (permalink / raw)
To: Juan J. Garcia de Soria, David Härdeman
Cc: Sean Young, linux-input@vger.kernel.org
Hi David and Juan,
I'm going through the various out-of-tree LIRC drivers to see if we
can stop shipping them in Arch Linux [0]. So far it appears we can
drop all except for lirc_wpc8769l [1] (PnP id WEC1020).
I noticed the comment in windownd-cir [2]:
* Currently supports the Winbond WPCD376i chip (PNP id WEC1022), but
* could probably support others (Winbond WEC102X, NatSemi, etc)
* with minor modifications.
What are your thoughts on adding support for WEC1020 upstream? Is
anyone interested in doing this work (I sadly don't have the correct
device, so can't really do it myself)?
Cheers,
Tom
[0]: <https://mailman.archlinux.org/pipermail/arch-dev-public/2013-October/025541.html>
[1]: <http://sourceforge.net/p/lirc/git/ci/master/tree/drivers/lirc_wpc8769l/>
[2]: <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/winbond-cir.c#n5>
^ permalink raw reply
* Re: [PATCHv2 3/3] HID:Kconfig: Correct MOMO description in wrong place (handled by LG4FF).
From: Jiri Kosina @ 2013-10-14 14:03 UTC (permalink / raw)
To: Elias Vanderstuyft, Simon Wood
Cc: linux-input, linux-kernel, Michal Malý
In-Reply-To: <CADbOyBQodqzSb04OCO6oduJSZvveZXxQjSdp+CdyKKk5Bs=O7w@mail.gmail.com>
On Thu, 10 Oct 2013, Elias Vanderstuyft wrote:
> I don't see any report-descriptor being fixed up, this results in having
> only two axes: steering and combined accel-brake axis.
> So, same procedure as the Formula Vibration wheel, I'll send you the report
> descriptor and some hidraw data when using the accel and brake pedals, in
> my next mail.
So should I wait for v3, where the rdesc fixup for splitting the axes will
be done, or are you planning to submit it to me as a followup patch?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: WPC8769L (WEC1020) support in winbond-cir?
From: Mauro Carvalho Chehab @ 2013-10-14 14:07 UTC (permalink / raw)
To: Tom Gundersen
Cc: Juan J. Garcia de Soria, David Härdeman, Sean Young,
linux-input@vger.kernel.org, LMML
In-Reply-To: <CAG-2HqX-TO7h8zJ6F01r2LfRVjQtb0pK_1wKGsYVKzB0zC7TQA@mail.gmail.com>
Hi Tom,
Em Mon, 14 Oct 2013 15:16:20 +0200
Tom Gundersen <teg@jklm.no> escreveu:
> Hi David and Juan,
>
> I'm going through the various out-of-tree LIRC drivers to see if we
> can stop shipping them in Arch Linux [0]. So far it appears we can
> drop all except for lirc_wpc8769l [1] (PnP id WEC1020).
Please copy the Linux Media ML to all Remote Controller drivers. There's
where we're discussing those drivers. No need to c/c linux-input.
Yeah, both lirc_atiusb and lirc_i2c were now obsoleted by upstream
non-staging drivers. I suggest to just drop it from Arch Linux.
Not sure about lirc_wpc8769l. David/Sean/Juan can have a better view.
Btw, there are also a number of lirc staging drivers under
drivers/staging/media/lirc/. We'd love some help trying to convert them
to use the rc core, moving them out of staging.
>
> I noticed the comment in windownd-cir [2]:
>
> * Currently supports the Winbond WPCD376i chip (PNP id WEC1022), but
> * could probably support others (Winbond WEC102X, NatSemi, etc)
> * with minor modifications.
>
> What are your thoughts on adding support for WEC1020 upstream? Is
> anyone interested in doing this work (I sadly don't have the correct
> device, so can't really do it myself)?
>
> Cheers,
>
> Tom
>
> [0]: <https://mailman.archlinux.org/pipermail/arch-dev-public/2013-October/025541.html>
> [1]: <http://sourceforge.net/p/lirc/git/ci/master/tree/drivers/lirc_wpc8769l/>
> [2]: <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/winbond-cir.c#n5>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Mauro
^ permalink raw reply
* Re: WPC8769L (WEC1020) support in winbond-cir?
From: Tom Gundersen @ 2013-10-14 14:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Juan J. Garcia de Soria, David Härdeman, Sean Young,
linux-input@vger.kernel.org, LMML
In-Reply-To: <20131014110748.366ea45e@samsung.com>
On Mon, Oct 14, 2013 at 4:07 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> Hi Tom,
>
> Em Mon, 14 Oct 2013 15:16:20 +0200
> Tom Gundersen <teg@jklm.no> escreveu:
>
>> Hi David and Juan,
>>
>> I'm going through the various out-of-tree LIRC drivers to see if we
>> can stop shipping them in Arch Linux [0]. So far it appears we can
>> drop all except for lirc_wpc8769l [1] (PnP id WEC1020).
>
> Please copy the Linux Media ML to all Remote Controller drivers. There's
> where we're discussing those drivers. No need to c/c linux-input.
>
> Yeah, both lirc_atiusb and lirc_i2c were now obsoleted by upstream
> non-staging drivers. I suggest to just drop it from Arch Linux.
Thanks for the info, we'll drop those drivers.
Cheers,
Tom
^ permalink raw reply
* Re: [PATCHv2 3/3] HID:Kconfig: Correct MOMO description in wrong place (handled by LG4FF).
From: simon @ 2013-10-14 14:58 UTC (permalink / raw)
To: Jiri Kosina
Cc: Elias Vanderstuyft, Simon Wood, linux-input, linux-kernel,
"Michal Malý"
In-Reply-To: <alpine.LNX.2.00.1310141602540.12405@pobox.suse.cz>
> On Thu, 10 Oct 2013, Elias Vanderstuyft wrote:
>
>> I don't see any report-descriptor being fixed up, this results in having
>> only two axes: steering and combined accel-brake axis.
>> So, same procedure as the Formula Vibration wheel, I'll send you the
>> report
>> descriptor and some hidraw data when using the accel and brake pedals,
>> in
>> my next mail.
>
> So should I wait for v3, where the rdesc fixup for splitting the axes will
> be done, or are you planning to submit it to me as a followup patch?
The HID descriptor for the MOMO Black was re-written in part2 of the patch
series:
https://patchwork.kernel.org/patch/3016111/
Simon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox