headers
Nestor Lopez Casado | 17 May 2013 13:47
Favicon

HID vendor access from user space

Hi,

In today's linux HID subsystem, a HID device can be accessed for
control and configuration via dev/hidraw, via a hid-specific driver,
as well as /dev/input (setting leds on a kbd for instance)

Some HID devices share multiple functionality in the same HID
interface, think of a keyboard with a touchpad and a vendor specific
collection for configuration, special status, etc.

For such device, there will be one hidraw node, and hid-input will
take care of parsing the keyboard/mouse collections into the proper
input objects.

The vendor collection will be ignored.

If a user wants to configure/control the device there are two choices,
either write a hid-specific driver to deal with the vendor specific
collection, or open the corresponding /hidraw node from userspace.

But a hidraw node that carries system input data requires root priviledges.

I'm interested in hearing your opinions on how to add the capability
for a normal user process to control/configure a HID device via
reports exchanged with a vendor collection.

I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
for all top level HID collections which are today ignored by hid-input
and/or other subsystems.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Shevchenko | 17 May 2013 13:34
Picon

[PATCH v3 0/2] hid: sort id list for eGalax and remove dups

Third version of the patches addresses comments I got from Benjamin and Jiri.
The actual change is the commit message for patch 2/2. Patch itself is remained
as in the first version.

Andy Shevchenko (2):
  hid: sort IDs for D-WAV eGalax multitouch devices
  hid: remove duplicate ID for D-WAV eGalax 0x7224

 drivers/hid/hid-ids.h        |  7 +++----
 drivers/hid/hid-multitouch.c | 29 +++++++++++++----------------
 2 files changed, 16 insertions(+), 20 deletions(-)

--

-- 
1.8.2.rc0.22.gb3600c3

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Steffen Trumtrar | 16 May 2013 11:49
Picon
Favicon

[PATCH] HID: multitouch: add support for Data Modul easyMaxTouch

Add vendor ID for Data Modul and their easyMaxTouch device.
The device has to be configured to multitouch mode prior to using this driver.

Signed-off-by: Steffen Trumtrar <s.trumtrar <at> pengutronix.de>
---
 drivers/hid/hid-ids.h        | 3 +++
 drivers/hid/hid-multitouch.c | 5 +++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 38535c9..0b4598a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
 <at>  <at>  -248,6 +248,9  <at>  <at> 
 #define USB_DEVICE_ID_CYPRESS_BARCODE_4	0xed81
 #define USB_DEVICE_ID_CYPRESS_TRUETOUCH	0xc001

+#define USB_VENDOR_ID_DATA_MODUL	0x7374
+#define USB_VENDOR_ID_DATA_MODUL_EASYMAXTOUCH	0x1201
+
 #define USB_VENDOR_ID_DEALEXTREAME	0x10c5
 #define USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701	0x819a

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index dc3ae5c..1bea657 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
 <at>  <at>  -1108,6 +1108,11  <at>  <at>  static const struct hid_device_id mt_devices[] = {
 		HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
 			USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Tissoires | 14 May 2013 16:21
Picon

Support of Genius mouse with huge max_usage

Hi Jiri,

I have a bug from an owner of a Gila mouse from Genius which I'm not
sure how to handle it:
https://bugzilla.redhat.com/show_bug.cgi?id=959721

The user gave me the hid-replay traces and within the first trace (the
one from hidraw0), I can extract the culprit collection:

0x05, 0x0c,                    // Usage Page (Consumer Devices)       104
0x09, 0x01,                    // Usage (Consumer Control)            106
0xa1, 0x01,                    // Collection (Application)            108
0x85, 0x03,                    //   Report ID (3)                     110
0x19, 0x00,                    //   Usage Minimum (0)                 112
0x2a, 0xff, 0x7f,              //   Usage Maximum (32767)             114
0x15, 0x00,                    //   Logical Minimum (0)               117
0x26, 0xff, 0x7f,              //   Logical Maximum (32767)           119
0x75, 0x10,                    //   Report Size (16)                  122
0x95, 0x03,                    //   Report Count (3)                  124
0x81, 0x00,                    //   Input (Data,Arr,Abs)              126
0x75, 0x08,                    //   Report Size (8)                   128
0x95, 0x01,                    //   Report Count (1)                  130
0x81, 0x01,                    //   Input (Cnst,Arr,Abs)              132
0xc0,                          // End Collection                      134

This hid device declares an array of 32767 usages, but HID_MAX_USAGES
is set to 12288 as mentioned in the bug.
One solution (given in the bug) consists in setting HID_MAX_USAGES to
32767, but I'm not very comfortable with this large value which will
impact all the existing hid devices.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Nicoletti | 13 May 2013 23:43
Picon
Gravatar

PATCH change for HID_BATTERY_STRENGTH kconfig

Hi,
I'd like to propose this patch while removes the need for
hid to be compiled build-in, as this is the same behavior
that WiiMote and Wacom have.
Is this ok?

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index fb52f3f..d6d85ad 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
 <at>  <at>  -27,7 +27,8  <at>  <at>  if HID

 config HID_BATTERY_STRENGTH
        bool "Battery level reporting for HID devices"
-       depends on HID && POWER_SUPPLY && HID = POWER_SUPPLY
+       depends on HID
+       select POWER_SUPPLY
        default n
        ---help---
        This option adds support of reporting battery strength (for HID devices
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ping Cheng | 13 May 2013 19:44
Picon

[PATCH] input : wacom - add an eraser to DTH2242/DTK2241

plus send begin and end of express keys events for
Cintiq 13HD and DTH2242/DTK2241

Signed-off-by: Ping Cheng <pingc <at> wacom.com>
---
 drivers/input/tablet/wacom_wac.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 2bc7839..518282d 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
 <at>  <at>  -362,7 +362,7  <at>  <at>  static int wacom_intuos_inout(struct wacom_wac *wacom)
 		case 0x100804: /* Intuos4/5 13HD/24HD Art Pen */
 		case 0x140802: /* Intuos4/5 13HD/24HD Classic Pen */
 		case 0x160802: /* Cintiq 13HD Pro Pen */
-		case 0x180802: /* DTH2242 Grip Pen */
+		case 0x180802: /* DTH2242 Pen */
 			wacom->tool[idx] = BTN_TOOL_PEN;
 			break;

 <at>  <at>  -400,6 +400,7  <at>  <at>  static int wacom_intuos_inout(struct wacom_wac *wacom)
 		case 0x10090a: /* Intuos4/5 13HD/24HD Airbrush Eraser */
 		case 0x10080c: /* Intuos4/5 13HD/24HD Art Pen Eraser */
 		case 0x16080a: /* Cintiq 13HD Pro Pen Eraser */
+		case 0x18080a: /* DTH2242 Eraser */
 			wacom->tool[idx] = BTN_TOOL_RUBBER;
 			break;

 <at>  <at>  -550,6 +551,11  <at>  <at>  static int wacom_intuos_irq(struct wacom_wac *wacom)
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Herrmann | 13 May 2013 17:01
Picon
Gravatar

[PATCH] HID: input: return ENODATA if reading battery attrs fails

power_supply core has the bad habit of calling our battery callbacks
from within power_supply_register(). Furthermore, if the callbacks
fail with an unhandled error code, it will skip any uevent that it
might currently process.
So if HID-core registers battery devices, an "add" uevent is generated
and the battery callbacks are called. These will gracefully fail due
to timeouts as they might still hold locks on event processing. One
could argue that this should be fixed in power_supply core, but the
least we can do is to signal ENODATA so power_supply core will just
skip the property and continue with the uevent.

This fixes a bug where "add" and "remove" uevents are skipped for
battery devices. upower is unable to track these devices and currently
needs to ignore them.

This patch also overwrites any other error code. I cannot see any reason
why we should forward protocol- or I/O-errors to the power_supply core.
We handle these errors in hid_ll_driver later, anyway, so just skip
them. power_supply core cannot do anything useful with them, anyway,
and we avoid skipping important uevents and confusing user-space.

Thanks a lot to Daniel Nicoletti for pushing and investigating
on this.

Cc: Jiri Kosina <jkosina <at> suse.cz>
Cc: Anton Vorontsov <cbou <at> mail.ru>
Cc: David Woodhouse <dwmw2 <at> infradead.org>
Reported-by: Daniel Nicoletti <dantti12 <at> gmail.com>
Signed-off-by: David Herrmann <dh.herrmann <at> gmail.com>
---
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Mack | 12 May 2013 18:50
Picon
Gravatar

[PATCH v2 1/2] Input: touchscreen: ads7846: keep copy of pdata in private struct

Allocate a copy of the pdata, and keep a pointer to it in the private
struct ads7846. Also, kill some members that used to be in both structs.

This is needed for the upcoming DT support.

Signed-off-by: Daniel Mack <zonque <at> gmail.com>
---

Hi Dmitry,

this is the alternative approach, as described eariler in our email
thread. It works equally well.

Thanks for having another look.

Daniel

 drivers/input/touchscreen/ads7846.c | 78 ++++++++++++++++++++-----------------
 1 file changed, 43 insertions(+), 35 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 84ccf14..198677d 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
 <at>  <at>  -104,12 +104,8  <at>  <at>  struct ads7846 {
 #endif

 	u16			model;
-	u16			vref_mv;
 	u16			vref_delay_usecs;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Filip Wieladek | 12 May 2013 09:31
Picon

Writing a Kernel driver for logitech G710+

I wanted to implement a kernel level driver for the keyboard G710+. I
know that there was previous discussions here:
http://www.spinics.net/lists/linux-input/msg25572.html but these did
not lead to any results yet.

I have written my first draft of the keyboard driver (available here
https://github.com/Wattos/logitech-g710-linux-driver) and now have
couple of questions, since I am most likely doing some things
incorrectly since this is my first time writing a kernel driver.

Firstly, The device registers as two different hid devices with their
own driver each. One device gets the "real" keyboard presses, and the
other one gets the macro keys and is also responsible for
communicating with the keyboard (e.g. setting the led backlight
level).  That might not sound like a terribly big issue, but it
complicates things in user space. My guess is that it is due to the
interface descriptors ( lsusb output -
https://github.com/K900/g710/blob/master/lsusb). The problem in
userspace comes from the fact that I am surfacing additional
properties (e.g. setting backlight level...), and it is more
convoluted for the userspace program to pick the correct "device". It
would even become more complex with multiple of these (granted, I
don't think anyone connects two the same keyboards...)

Secondly, I am handling the raw even of the macro key manually.
Instead I have the feeling that I should be using input_mapping and
let the generic hid driver do its magic. The input events for the
macro keys look very similar to media buttons on the keyboard which
actually work out of the box. I have captured the calls to the
input_mapping here:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ferruh Yigit | 10 May 2013 15:32
Favicon

[PATCH 1/2] Input: cyttsp - fix memcpy size param

memcpy param is wrong because of offset in bl_cmd, this may corrupt the
stack which may cause a crash.

Tested-by: Ferruh Yigit <fery <at> cypress.com> on TMA300-DVK
Signed-off-by: Ferruh Yigit <fery <at> cypress.com>
---
 drivers/input/touchscreen/cyttsp_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/cyttsp_core.c b/drivers/input/touchscreen/cyttsp_core.c
index 8e60437..97ba891 100644
--- a/drivers/input/touchscreen/cyttsp_core.c
+++ b/drivers/input/touchscreen/cyttsp_core.c
 <at>  <at>  -133,7 +133,7  <at>  <at>  static int cyttsp_exit_bl_mode(struct cyttsp *ts)
        memcpy(bl_cmd, bl_command, sizeof(bl_command));
        if (ts->pdata->bl_keys)
                memcpy(&bl_cmd[sizeof(bl_command) - CY_NUM_BL_KEYS],
-                       ts->pdata->bl_keys, sizeof(bl_command));
+                       ts->pdata->bl_keys, CY_NUM_BL_KEYS);

        error = ttsp_write_block_data(ts, CY_REG_BASE,
                                      sizeof(bl_cmd), bl_cmd);
--
1.7.9.5

This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If
it has been received in error, please advise the sender and immediately delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tibor Billes | 9 May 2013 22:59
Picon
Favicon

Possible regression 3.8.7 -> 3.9 with Dell touchpad

Hi,

I found that after upgrading my kernel from 3.8.7 to 3.9 my touchpad only
works partly. By that I mean I can use the touchpad to move the cursor
around, but I cannot click with it by tapping. My machine is a Dell
Latitude E5530. Since it is 100% reproducible on my machine, I bisected it,
and found this commit:

commit 1302bac33d9e88cd43e482191a806998f3ed43cc
Author: Kevin Cernekee <cernekee <at> gmail.com>
Date:   Wed Feb 13 22:27:08 2013 -0800

    Input: ALPS - add support for "Rushmore" touchpads
    
    Rushmore touchpads are found on Dell E6230/E6430/E6530.  They use the V3
    protocol with slightly tweaked init sequences and report formats.
    
    The E7 report is 73 03 0a, and the EC report is 88 08 1d
    
    Credits: Emmanuel Thome reported the MT bitmap changes.
    
    Signed-off-by: Kevin Cernekee <cernekee <at> gmail.com>
    Tested-by: Dave Turvene <dturvene <at> dahetral.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov <at> gmail.com>

I did the bisection between 3.8.7 and 3.9, but also tried 3.9.1, it is bad
too. I also tried reverting that commit to make sure that it really is
what made my touchpad not working. The revert did fix my problem.

That's all I gathered so far, but I'd be happy to help further in any way
(Continue reading)

Permalink | Reply | 3 comments |

Gmane