* Re: Sony DualShock4 - basic functions work, but looking to improve support
From: simon @ 2013-12-10 2:50 UTC (permalink / raw)
To: David Herrmann; +Cc: Linux Input, Antonio Ospite
In-Reply-To: <CANq1E4Q=4DEDFibVtifMVE-2wq7Bt0KOPRRE5nFy9Hu-tgy_Cg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
> The report descriptor actually describes a lot more report-IDs than
> just "0x01" which you describe in hidraw.txt. Are you sure the
> report-descriptors are the same for USB and BT?
The report descriptor when connected via BT is different, or at least what
I found at '/sys/bus/hid/devices/0005\:054C\:05C4.0006/report_descriptor'.
Unfortunately I wasn't able to decode it.
--
simon@womble:~/dualshock4$ ~/hidrd-0.2.0/src/hidrd-convert des_bt.bin -o code
Failed to read input item at offset 356:
invalid item encountered
--
Thanks for the other suggestions.
Simon
[-- Attachment #2: des_bt.bin --]
[-- Type: application/octet-stream, Size: 357 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: dt: Document TSC2005 DT binding
From: Tony Lindgren @ 2013-12-10 0:06 UTC (permalink / raw)
To: Dmitry Torokhov, Dmitry Torokhov, linux-input, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Rob Landley, Grant Likely, devicetree, linux-omap, linux-kernel
In-Reply-To: <20131209182409.GA7626@earth.universe>
* Sebastian Reichel <sre@debian.org> [131209 10:25]:
> On Mon, Dec 09, 2013 at 09:46:38AM -0800, Tony Lindgren wrote:
> > > +Optional properties:
> > > + - ti,fuzz-x : integer, X noise value of the touchscreen
> > > + (defaults to 4)
> > > + - ti,fuzz-y : integer, Y noise value of the touchscreen
> > > + (defaults to 8)
> > > + - ti,fuzz-pressure : integer, pressure noise value of the touchscreen
> > > + (defaults to 2)
> > > + - ti,max-x : integer, maximum reported x value
> > > + (defaults to 4096)
> > > + - ti,max-y : integer, maximum reported y value
> > > + (defaults to 4096)
> > > + - ti,max-pressure : integer, maximum reported pressure
> > > + (defaults to 4096)
> > > + - ti,x-plate-resistance : integer, resistance of the touchscreen's X plates
> > > + in ohm (defaults to 280)
> > > + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
> > > + the configured time (in milli seconds), the driver
> > > + will reset it. This is disabled by default.
> >
> > Instead of adding these optional ti,* properties you can set them in the
> > driver directly in the of_match table based on the compatible flag. Then
> > you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of
> > the LCD panel. Most likely these depend on the LCD panel selected.
>
> I could certainly do this, but it would move the board specific data
> from the boardcode into the driver. That looks contra-productive to
> me. Is there a good reason to do it this way?
You can leave out the custom properties that way for something that probably
should be grouped by the touchpanel type connected as the values are the
same.
So for example just a few compatible flags like ti,tsc2005-panel-abc and
ti,tsc2005-panel-xyz we could potentially cover all the configurations
we're aware of without any need for custom properties. And this is way
easier to support in the long run assuming we don't end up with tons of
compatible flags. Of course if we end up with a new compatible flag for
each configuration, then it makes sense to set up the custom properties,
but I doubt that's the case here.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] input synaptics-rmi4: elliminate multiple sensor support from rmi_f11.c
From: Benjamin Tissoires @ 2013-12-09 21:03 UTC (permalink / raw)
To: Andrew Duggan, Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij
In-Reply-To: <1386295167-866-1-git-send-email-aduggan@synaptics.com>
On 05/12/13 20:59, Andrew Duggan wrote:
> This patch implements changes to the synaptics-rmi4 branch of
> Dmitry's input tree. The base for the patch is commit
> 8ca01dc61a42b6f7bcba052a8c084000f7057a34.
FWIW, these three lines above could (should) go after the very first
"---" before the stats. This way, you will tell the list which base is
the patch based, but this will not go into Linus' tree (which would be
irrelevant).
>
> This patch elliminates support for multiple sensors in rmi_f11. This feature
> has been removed from the RMI4 spec and no devices have every used multiple
> F11 sensors on a single device.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
I did not saw anything but what the commit message claims. So:
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH V2] input synaptics-rmi4: Reorder declarations in rmi_bus.c
From: Benjamin Tissoires @ 2013-12-09 20:14 UTC (permalink / raw)
To: Christopher Heiny, Dmitry Torokhov
Cc: Linux Input, Andrew Duggan, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij
In-Reply-To: <1386289756-12429-1-git-send-email-cheiny@synaptics.com>
Hi Chris,
On 05/12/13 19:29, Christopher Heiny wrote:
> This patch implements changes to the synaptics-rmi4 branch of
> Dmitry's input tree. The base for the patch is commit
> 8ca01dc61a42b6f7bcba052a8c084000f7057a34.
>
> This patch primarily reorders the various declarations in rmi_bus.c in order to
> group related elements together, along with some typo fixes. The code is still
> horribly broken, but this change should make the following fixes easier to
> review.
>
> Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Linus Walleij <linus.walleij@stericsson.com>
> Cc: Joerie de Gram <j.de.gram@gmail.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> ---
FWIW, I made a review of the patch.
The patches does not only reorder the functions, but also fix some few
things I will detail later (plus fixes of whitespace/comments issues).
It also changes the exported functions as GPL.
Dmitry, given the current state of the driver (which does not work at
all if I understood correctly), maybe you can pick this one in its
current state.
> drivers/input/rmi4/rmi_bus.c | 189 +++++++++++++++++++++----------------------
> 1 file changed, 90 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
> index 88f60ca..d9c450b 100644
> --- a/drivers/input/rmi4/rmi_bus.c
> +++ b/drivers/input/rmi4/rmi_bus.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2011, 2012 Synaptics Incorporated
> + * Copyright (c) 2011-2013 Synaptics Incorporated
> * Copyright (c) 2011 Unixphere
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -19,77 +19,20 @@
> #include "rmi_bus.h"
> #include "rmi_driver.h"
>
> -static int rmi_function_match(struct device *dev, struct device_driver *drv)
> -{
> - struct rmi_function_handler *handler = to_rmi_function_handler(drv);
> - struct rmi_function *fn = to_rmi_function(dev);
> -
> - return fn->fd.function_number == handler->func;
> -}
> -
> -static int rmi_bus_match(struct device *dev, struct device_driver *drv)
> -{
> - bool physical = rmi_is_physical_device(dev);
> -
> - /* First see if types are not compatible */
> - if (physical != rmi_is_physical_driver(drv))
> - return 0;
> -
> - return physical || rmi_function_match(dev, drv);
> -}
> -
> -struct bus_type rmi_bus_type = {
> - .match = rmi_bus_match,
> - .name = "rmi",
> -};
> -
> -#ifdef CONFIG_RMI4_DEBUG
> -
> -static struct dentry *rmi_debugfs_root;
> -
> -static void rmi_bus_setup_debugfs(void)
> -{
> - rmi_debugfs_root = debugfs_create_dir(rmi_bus_type.name, NULL);
> - if (!rmi_debugfs_root)
> - pr_err("%s: Failed to create debugfs root\n",
> - __func__);
> -}
> -
> -static void rmi_bus_teardown_debugfs(void)
> -{
> - if (rmi_debugfs_root)
> - debugfs_remove_recursive(rmi_debugfs_root);
> -}
> -
> -#else
> -
> -static void rmi_bus_setup_debugfs(void)
> -{
> -}
> -
> -static void rmi_bus_teardown_debugfs(void)
> -{
> -}
> -
> -#endif
> -
> -
> /*
> * RMI Physical devices
> *
> * Physical RMI device consists of several functions serving particular
> - * purpose. For example F11 is a 2D touch sensor while F10 is a generic
> + * purpose. For example F11 is a 2D touch sensor while F01 is a generic
> * function present in every RMI device.
> */
>
> static void rmi_release_device(struct device *dev)
> {
> struct rmi_device *rmi_dev = to_rmi_device(dev);
> -
> kfree(rmi_dev);
> }
>
> -/* Device type for physical RMI devices */
> struct device_type rmi_device_type = {
> .name = "rmi_sensor",
> .release = rmi_release_device,
> @@ -118,7 +61,7 @@ static void rmi_physical_teardown_debugfs(struct rmi_device *rmi_dev)
>
> #else
>
> -static void rmi_physocal_setup_debugfs(struct rmi_device *rmi_dev)
> +static void rmi_physical_setup_debugfs(struct rmi_device *rmi_dev)
This typo makes me wonder how nobody saw this before. This will not
compile without CONFIG_RMI4_DEBUG... :(
> {
> }
>
> @@ -128,7 +71,6 @@ static void rmi_physical_teardown_debugfs(struct rmi_device *rmi_dev)
>
> #endif
>
> -
> /**
> * rmi_register_physical_device - register a physical device connection on the RMI
> * bus. Physical drivers provide communication from the devices on the bus to
> @@ -174,7 +116,7 @@ int rmi_register_physical_device(struct rmi_phys_device *phys)
>
> return 0;
> }
> -EXPORT_SYMBOL(rmi_register_physical_device);
> +EXPORT_SYMBOL_GPL(rmi_register_physical_device);
>
> /**
> * rmi_unregister_physical_device - unregister a physical device connection
> @@ -191,18 +133,14 @@ void rmi_unregister_physical_device(struct rmi_phys_device *phys)
> EXPORT_SYMBOL(rmi_unregister_physical_device);
>
>
> -/*
> - * RMI Function devices and their handlers
> - */
> +/* Function specific stuff */
>
> static void rmi_release_function(struct device *dev)
> {
> struct rmi_function *fn = to_rmi_function(dev);
> -
> kfree(fn);
> }
>
> -/* Device type for RMI Function devices */
> struct device_type rmi_function_type = {
> .name = "rmi_function",
> .release = rmi_release_function,
> @@ -244,35 +182,12 @@ static void rmi_function_teardown_debugfs(struct rmi_function *fn)
>
> #endif
>
> -int rmi_register_function(struct rmi_function *fn)
> +static int rmi_function_match(struct device *dev, struct device_driver *drv)
> {
> - struct rmi_device *rmi_dev = fn->rmi_dev;
> - int error;
> -
> - dev_set_name(&fn->dev, "%s.fn%02x",
> - dev_name(&rmi_dev->dev), fn->fd.function_number);
> -
> - fn->dev.parent = &rmi_dev->dev;
> - fn->dev.type = &rmi_function_type;
> - fn->dev.bus = &rmi_bus_type;
> -
> - error = device_register(&fn->dev);
> - if (error) {
> - dev_err(&rmi_dev->dev,
> - "Failed device_register function device %s\n",
> - dev_name(&fn->dev));
> - }
> -
> - dev_dbg(&rmi_dev->dev, "Registered F%02X.\n", fn->fd.function_number);
> -
> - rmi_function_setup_debugfs(fn);
> - return 0;
> -}
> + struct rmi_function_handler *handler = to_rmi_function_handler(drv);
> + struct rmi_function *fn = to_rmi_function(dev);
>
> -void rmi_unregister_function(struct rmi_function *fn)
> -{
> - rmi_function_teardown_debugfs(fn);
> - device_unregister(&fn->dev);
> + return fn->fd.function_number == handler->func;
> }
>
> static int rmi_function_probe(struct device *dev)
> @@ -302,6 +217,38 @@ static int rmi_function_remove(struct device *dev)
> return 0;
> }
>
> +int rmi_register_function(struct rmi_function *fn)
> +{
> + struct rmi_device *rmi_dev = fn->rmi_dev;
> + int error;
> +
> + dev_set_name(&fn->dev, "%s.fn%02x",
> + dev_name(&rmi_dev->dev), fn->fd.function_number);
> +
> + fn->dev.parent = &rmi_dev->dev;
> + fn->dev.type = &rmi_function_type;
> + fn->dev.bus = &rmi_bus_type;
> +
> + error = device_register(&fn->dev);
> + if (error) {
> + dev_err(&rmi_dev->dev,
> + "Failed device_register function device %s\n",
> + dev_name(&fn->dev));
> + return error;
this return statement was not in the previous version of rmi_bus.c, but
it looks obviously correct.
So to sum up:
Reviewed-by: benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
> + }
> +
> + dev_dbg(&rmi_dev->dev, "Registered F%02X.\n", fn->fd.function_number);
> +
> + rmi_function_setup_debugfs(fn);
> + return 0;
> +}
> +
> +void rmi_unregister_function(struct rmi_function *fn)
> +{
> + rmi_function_teardown_debugfs(fn);
> + device_unregister(&fn->dev);
> +}
> +
> /**
> * rmi_register_function_handler - register a handler for an RMI function
> * @handler: RMI handler that should be registered.
> @@ -334,7 +281,7 @@ int __rmi_register_function_handler(struct rmi_function_handler *handler,
>
> return 0;
> }
> -EXPORT_SYMBOL(__rmi_register_function_handler);
> +EXPORT_SYMBOL_GPL(__rmi_register_function_handler);
>
> /**
> * rmi_unregister_function_handler - unregister given RMI function handler
> @@ -347,11 +294,55 @@ void rmi_unregister_function_handler(struct rmi_function_handler *handler)
> {
> driver_unregister(&handler->driver);
> }
> -EXPORT_SYMBOL(rmi_unregister_function_handler);
> +EXPORT_SYMBOL_GPL(rmi_unregister_function_handler);
>
> -/*
> - * Bus registration and tear-down
> - */
> +/* Bus specific stuff */
> +
> +static int rmi_bus_match(struct device *dev, struct device_driver *drv)
> +{
> + bool physical = rmi_is_physical_device(dev);
> +
> + /* First see if types are not compatible */
> + if (physical != rmi_is_physical_driver(drv))
> + return 0;
> +
> + return physical || rmi_function_match(dev, drv);
> +}
> +
> +struct bus_type rmi_bus_type = {
> + .match = rmi_bus_match,
> + .name = "rmi",
> +};
> +
> +#ifdef CONFIG_RMI4_DEBUG
> +
> +static struct dentry *rmi_debugfs_root;
> +
> +static void rmi_bus_setup_debugfs(void)
> +{
> + rmi_debugfs_root = debugfs_create_dir(rmi_bus_type.name, NULL);
> + if (!rmi_debugfs_root)
> + pr_err("%s: Failed to create debugfs root\n",
> + __func__);
> +}
> +
> +static void rmi_bus_teardown_debugfs(void)
> +{
> + if (rmi_debugfs_root)
> + debugfs_remove_recursive(rmi_debugfs_root);
> +}
> +
> +#else
> +
> +static void rmi_bus_setup_debugfs(void)
> +{
> +}
> +
> +static void rmi_bus_teardown_debugfs(void)
> +{
> +}
> +
> +#endif
>
> static int __init rmi_bus_init(void)
> {
>
^ permalink raw reply
* Re: [PATCH 1/2] elantech: Properly differentiate between clickpads and normal touchpads
From: Benjamin Tissoires @ 2013-12-09 19:21 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-input, Peter Hutterer, Duson Lin, Dmitry Torokhov
In-Reply-To: <52A6169C.1020904@redhat.com>
On Mon, Dec 9, 2013 at 2:14 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 12/09/2013 07:02 PM, Benjamin Tissoires wrote:
>>
>> Hi Hans,
>>
>> adding in CC Duson, who seems to be working on the same driver
>> currently, and Dmitry, the input maintainer.
>>
>> On Mon, Dec 9, 2013 at 9:32 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> The current assumption in the elantech driver that hw version 3 touchpads
>>> are
>>> never clickpads and hw version 4 touchpads are always clickpads is wrong.
>>>
>>> There are several bug reports for this, ie:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1030802
>>>
>>> http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux
>>>
>>> I've spend a couple of hours wading through various bugzillas,
>>> launchpads and forum posts to create a list of fw-versions and
>>> capabilities
>>> for different laptop models to find a good method to differentiate
>>> between
>>> clickpads and versions with separate hardware buttons.
>>>
>>> Which shows that a device being a clickpad is reliable indicated by bit
>>> 12
>>> being set in the fw_version. I've included the gathered list inside the
>>> driver,
>>> so that we've this info at hand if we need to revisit this later.
>>
>>
>> Duson, can you confirm this? It's not that I don't trust Hans, but if
>> we could have the hardware maker validating this part, this would be
>> great.
>>
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/input/mouse/elantech.c | 43
>>> +++++++++++++++++++++++++++++++++++++++---
>>> 1 file changed, 40 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/input/mouse/elantech.c
>>> b/drivers/input/mouse/elantech.c
>>> index 8551dca..f7baa32 100644
>>> --- a/drivers/input/mouse/elantech.c
>>> +++ b/drivers/input/mouse/elantech.c
>>> @@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse
>>> *psmouse)
>>> unsigned char *packet = psmouse->packet;
>>>
>>> input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
>>> + input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
>>> input_mt_report_pointer_emulation(dev, true);
>>> input_sync(dev);
>>> }
>>> @@ -984,6 +985,42 @@ static int elantech_get_resolution_v4(struct psmouse
>>> *psmouse,
>>> }
>>>
>>> /*
>>> + * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12
>>> in
>>> + * fw_version for this is based on the following fw_version & caps
>>> table:
>>> + *
>>> + * Laptop-model: fw_version: caps: buttons:
>>> + * Acer S3 0x461f00 10, 13, 0e clickpad
>>> + * Acer S7-392 0x581f01 50, 17, 0d clickpad
>>> + * Acer V5-131 0x461f02 01, 16, 0c clickpad
>>> + * Acer V5-551 0x461f00 ? clickpad
>>> + * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
>>> + * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
>>> + * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
>>> + * Asus UX31 0x361f00 20, 15, 0e clickpad
>>> + * Asus UX32VD 0x361f02 00, 15, 0e clickpad
>>> + * Avatar AVIU-145A2 0x361f00 ? clickpad
>>> + * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
>>> + * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons
>>> (*)
>>> + * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
>>> + * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
>>> + * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
>>> + * Samsung NP900X3E-A02 0x575f03 ? clickpad
>>> + * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
>>> + * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
>>> + * Samsung RF710 0x450f00 ? 2 hw buttons
>>> + * System76 Pangolin 0x250f01 ? 2 hw buttons
>>> + * (*) + 3 trackpoint buttons
>>> + */
>>> +static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
>>> +{
>>> + struct input_dev *dev = psmouse->dev;
>>> + struct elantech_data *etd = psmouse->private;
>>> +
>>> + if (etd->fw_version & 0x001000)
>>> + __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
>>
>>
>> Small question here: if the touchpad is a clickpad, should'nt we also
>> remove the BTN_RIGHT bit too?
>
>
> We could, but I don't see much value in that, and it would also require
> if statements in the sync methods to ensure that we don't tree to send
> a button event for a button we don't advertise.
We don't need this test in the sync method. The test is already
implemented in input_event. So now, it's just a matter of taste
regarding upper layers. Peter, any thoughts on this?
Anyway, other than that:
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
>
> Regards,
>
> Hans
^ permalink raw reply
* Re: [PATCH 1/2] elantech: Properly differentiate between clickpads and normal touchpads
From: Hans de Goede @ 2013-12-09 19:14 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: linux-input, Peter Hutterer, Duson Lin, Dmitry Torokhov
In-Reply-To: <CAN+gG=Eh72eBS67db_KNsUzXRNsOUXB8YkzuuHoJca22xRAkdQ@mail.gmail.com>
Hi,
On 12/09/2013 07:02 PM, Benjamin Tissoires wrote:
> Hi Hans,
>
> adding in CC Duson, who seems to be working on the same driver
> currently, and Dmitry, the input maintainer.
>
> On Mon, Dec 9, 2013 at 9:32 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> The current assumption in the elantech driver that hw version 3 touchpads are
>> never clickpads and hw version 4 touchpads are always clickpads is wrong.
>>
>> There are several bug reports for this, ie:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1030802
>> http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux
>>
>> I've spend a couple of hours wading through various bugzillas,
>> launchpads and forum posts to create a list of fw-versions and capabilities
>> for different laptop models to find a good method to differentiate between
>> clickpads and versions with separate hardware buttons.
>>
>> Which shows that a device being a clickpad is reliable indicated by bit 12
>> being set in the fw_version. I've included the gathered list inside the driver,
>> so that we've this info at hand if we need to revisit this later.
>
> Duson, can you confirm this? It's not that I don't trust Hans, but if
> we could have the hardware maker validating this part, this would be
> great.
>
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/mouse/elantech.c | 43 +++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
>> index 8551dca..f7baa32 100644
>> --- a/drivers/input/mouse/elantech.c
>> +++ b/drivers/input/mouse/elantech.c
>> @@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
>> unsigned char *packet = psmouse->packet;
>>
>> input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
>> + input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
>> input_mt_report_pointer_emulation(dev, true);
>> input_sync(dev);
>> }
>> @@ -984,6 +985,42 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
>> }
>>
>> /*
>> + * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
>> + * fw_version for this is based on the following fw_version & caps table:
>> + *
>> + * Laptop-model: fw_version: caps: buttons:
>> + * Acer S3 0x461f00 10, 13, 0e clickpad
>> + * Acer S7-392 0x581f01 50, 17, 0d clickpad
>> + * Acer V5-131 0x461f02 01, 16, 0c clickpad
>> + * Acer V5-551 0x461f00 ? clickpad
>> + * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
>> + * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
>> + * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
>> + * Asus UX31 0x361f00 20, 15, 0e clickpad
>> + * Asus UX32VD 0x361f02 00, 15, 0e clickpad
>> + * Avatar AVIU-145A2 0x361f00 ? clickpad
>> + * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
>> + * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
>> + * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
>> + * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
>> + * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
>> + * Samsung NP900X3E-A02 0x575f03 ? clickpad
>> + * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
>> + * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
>> + * Samsung RF710 0x450f00 ? 2 hw buttons
>> + * System76 Pangolin 0x250f01 ? 2 hw buttons
>> + * (*) + 3 trackpoint buttons
>> + */
>> +static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
>> +{
>> + struct input_dev *dev = psmouse->dev;
>> + struct elantech_data *etd = psmouse->private;
>> +
>> + if (etd->fw_version & 0x001000)
>> + __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
>
> Small question here: if the touchpad is a clickpad, should'nt we also
> remove the BTN_RIGHT bit too?
We could, but I don't see much value in that, and it would also require
if statements in the sync methods to ensure that we don't tree to send
a button event for a button we don't advertise.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH V2] input synaptics-rmi4: Fix ms calculation in poll interval
From: Benjamin Tissoires @ 2013-12-09 18:53 UTC (permalink / raw)
To: Christopher Heiny, Dmitry Torokhov
Cc: Linux Input, Andrew Duggan, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij
In-Reply-To: <1386288825-11837-1-git-send-email-cheiny@synaptics.com>
On 05/12/13 19:13, Christopher Heiny wrote:
> [Previous patch re-used an old template for the subject line. Sorry about that]
>
> This patch implements changes to the synaptics-rmi4 branch of
> Dmitry's input tree. The base for the patch is commit
> 8ca01dc61a42b6f7bcba052a8c084000f7057a34.
>
> Fix computation of poll interval milliseconds.
>
> Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Linus Walleij <linus.walleij@stericsson.com>
> Cc: Joerie de Gram <j.de.gram@gmail.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
> ---
> drivers/input/rmi4/rmi_driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index 9af297e..dffbfa0 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -934,7 +934,7 @@ static int rmi_driver_probe(struct device *dev)
> } else
> data->poll_interval = ktime_set(0,
> (pdata->poll_interval_ms ? pdata->poll_interval_ms :
> - DEFAULT_POLL_INTERVAL_MS) * 1000);
> + DEFAULT_POLL_INTERVAL_MS) * 1000 * 1000);
>
> if (data->f01_container->dev.driver) {
> /* Driver already bound, so enable ATTN now. */
>
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: dt: Document TSC2005 DT binding
From: Sebastian Reichel @ 2013-12-09 18:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Dmitry Torokhov, Dmitry Torokhov, linux-input, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Rob Landley, Grant Likely, devicetree, linux-omap, linux-kernel
In-Reply-To: <20131209174638.GC12527@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]
On Mon, Dec 09, 2013 at 09:46:38AM -0800, Tony Lindgren wrote:
> > +Optional properties:
> > + - ti,fuzz-x : integer, X noise value of the touchscreen
> > + (defaults to 4)
> > + - ti,fuzz-y : integer, Y noise value of the touchscreen
> > + (defaults to 8)
> > + - ti,fuzz-pressure : integer, pressure noise value of the touchscreen
> > + (defaults to 2)
> > + - ti,max-x : integer, maximum reported x value
> > + (defaults to 4096)
> > + - ti,max-y : integer, maximum reported y value
> > + (defaults to 4096)
> > + - ti,max-pressure : integer, maximum reported pressure
> > + (defaults to 4096)
> > + - ti,x-plate-resistance : integer, resistance of the touchscreen's X plates
> > + in ohm (defaults to 280)
> > + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
> > + the configured time (in milli seconds), the driver
> > + will reset it. This is disabled by default.
>
> Instead of adding these optional ti,* properties you can set them in the
> driver directly in the of_match table based on the compatible flag. Then
> you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of
> the LCD panel. Most likely these depend on the LCD panel selected.
I could certainly do this, but it would move the board specific data
from the boardcode into the driver. That looks contra-productive to
me. Is there a good reason to do it this way?
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] elantech: Properly differentiate between clickpads and normal touchpads
From: Benjamin Tissoires @ 2013-12-09 18:02 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-input, Peter Hutterer, Duson Lin, Dmitry Torokhov
In-Reply-To: <1386599551-2339-1-git-send-email-hdegoede@redhat.com>
Hi Hans,
adding in CC Duson, who seems to be working on the same driver
currently, and Dmitry, the input maintainer.
On Mon, Dec 9, 2013 at 9:32 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> The current assumption in the elantech driver that hw version 3 touchpads are
> never clickpads and hw version 4 touchpads are always clickpads is wrong.
>
> There are several bug reports for this, ie:
> https://bugzilla.redhat.com/show_bug.cgi?id=1030802
> http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux
>
> I've spend a couple of hours wading through various bugzillas,
> launchpads and forum posts to create a list of fw-versions and capabilities
> for different laptop models to find a good method to differentiate between
> clickpads and versions with separate hardware buttons.
>
> Which shows that a device being a clickpad is reliable indicated by bit 12
> being set in the fw_version. I've included the gathered list inside the driver,
> so that we've this info at hand if we need to revisit this later.
Duson, can you confirm this? It's not that I don't trust Hans, but if
we could have the hardware maker validating this part, this would be
great.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/mouse/elantech.c | 43 +++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 8551dca..f7baa32 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
> unsigned char *packet = psmouse->packet;
>
> input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
> + input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
> input_mt_report_pointer_emulation(dev, true);
> input_sync(dev);
> }
> @@ -984,6 +985,42 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
> }
>
> /*
> + * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
> + * fw_version for this is based on the following fw_version & caps table:
> + *
> + * Laptop-model: fw_version: caps: buttons:
> + * Acer S3 0x461f00 10, 13, 0e clickpad
> + * Acer S7-392 0x581f01 50, 17, 0d clickpad
> + * Acer V5-131 0x461f02 01, 16, 0c clickpad
> + * Acer V5-551 0x461f00 ? clickpad
> + * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
> + * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
> + * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
> + * Asus UX31 0x361f00 20, 15, 0e clickpad
> + * Asus UX32VD 0x361f02 00, 15, 0e clickpad
> + * Avatar AVIU-145A2 0x361f00 ? clickpad
> + * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
> + * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
> + * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
> + * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
> + * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
> + * Samsung NP900X3E-A02 0x575f03 ? clickpad
> + * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
> + * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
> + * Samsung RF710 0x450f00 ? 2 hw buttons
> + * System76 Pangolin 0x250f01 ? 2 hw buttons
> + * (*) + 3 trackpoint buttons
> + */
> +static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
> +{
> + struct input_dev *dev = psmouse->dev;
> + struct elantech_data *etd = psmouse->private;
> +
> + if (etd->fw_version & 0x001000)
> + __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
Small question here: if the touchpad is a clickpad, should'nt we also
remove the BTN_RIGHT bit too?
Cheers,
Benjamin
> +}
> +
> +/*
> * Set the appropriate event bits for the input subsystem
> */
> static int elantech_set_input_params(struct psmouse *psmouse)
> @@ -1026,6 +1063,8 @@ static int elantech_set_input_params(struct psmouse *psmouse)
> __set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
> /* fall through */
> case 3:
> + if (etd->hw_version == 3)
> + elantech_set_buttonpad_prop(psmouse);
> input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
> input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
> if (etd->reports_pressure) {
> @@ -1047,9 +1086,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
> */
> psmouse_warn(psmouse, "couldn't query resolution data.\n");
> }
> - /* v4 is clickpad, with only one button. */
> - __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
> - __clear_bit(BTN_RIGHT, dev->keybit);
> + elantech_set_buttonpad_prop(psmouse);
> __set_bit(BTN_TOOL_QUADTAP, dev->keybit);
> /* For X to recognize me as touchpad. */
> input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
> --
> 1.8.4.2
>
> --
> 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
* Re: [PATCH 2/2] elantech: Add support for IC-body version 8
From: Benjamin Tissoires @ 2013-12-09 17:50 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-input, Peter Hutterer
In-Reply-To: <1386599551-2339-2-git-send-email-hdegoede@redhat.com>
On Mon, Dec 9, 2013 at 9:32 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Acording to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1232877
> a patch for this has been send before, but I don't see this in 3.13-rc3,
> so here is another one.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>
Hey Hans,
good to see you on linux-input :)
anyway, Dmitry already took this patch in his tree:
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=9cb80b965eaf7af1369f6e16f48a05fbaaccc021
And this patch is part of the pull request for 3.13-rc3 (so should be in rc4).
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: dt: Document TSC2005 DT binding
From: Tony Lindgren @ 2013-12-09 17:46 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, devicetree, linux-omap,
linux-kernel
In-Reply-To: <1386284979-9680-3-git-send-email-sre@debian.org>
* Sebastian Reichel <sre@debian.org> [131205 15:11]:
> Add devicetree binding documentation for TSC2005 touchscreen.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> .../bindings/input/touchscreen/tsc2005.txt | 49 ++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> new file mode 100644
> index 0000000..4e7df0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> @@ -0,0 +1,49 @@
> +* TSC2005 Touchscreen
> +
> +Required properties:
> + - compatible : "ti,tsc2005"
> + - reg : SPI device address
> + - spi-max-frequency : Maximal SPI speed
> + - interrupts : IRQ specifier
> + - reset-gpio : GPIO specifier
> +
> +Optional properties:
> + - ti,fuzz-x : integer, X noise value of the touchscreen
> + (defaults to 4)
> + - ti,fuzz-y : integer, Y noise value of the touchscreen
> + (defaults to 8)
> + - ti,fuzz-pressure : integer, pressure noise value of the touchscreen
> + (defaults to 2)
> + - ti,max-x : integer, maximum reported x value
> + (defaults to 4096)
> + - ti,max-y : integer, maximum reported y value
> + (defaults to 4096)
> + - ti,max-pressure : integer, maximum reported pressure
> + (defaults to 4096)
> + - ti,x-plate-resistance : integer, resistance of the touchscreen's X plates
> + in ohm (defaults to 280)
> + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
> + the configured time (in milli seconds), the driver
> + will reset it. This is disabled by default.
Instead of adding these optional ti,* properties you can set them in the
driver directly in the of_match table based on the compatible flag. Then
you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of
the LCD panel. Most likely these depend on the LCD panel selected.
Regards,
Tony
> +Example:
> +
> +&mcspi1 {
> + tsc2005@0 {
> + compatible = "ti,tsc2005";
> + spi-max-frequency = <6000000>;
> + reg = <0>;
> + reset-gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
> + interrupt-parent = <&gpio4>;
> + interrupts = <4 IRQ_TYPE_NONE>; /* gpio line 100 */
> +
> + ti,fuzz-x = <4>;
> + ti,fuzz-y = <7>;
> + ti,fuzz-pressure = <2>;
> + ti,max-x = <4096>;
> + ti,max-y = <4096>;
> + ti,max-pressure = <2048>;
> + ti,x-plate-resistance = <280>;
> + ti,esd-recovery-timeout-ms = <8000>;
> + };
> +}
> --
> 1.8.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* Re: [PATCH v1] HID: hid-sensor-hub: Fix kernel warning and failure
From: Jiri Kosina @ 2013-12-09 14:46 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: linux-input
In-Reply-To: <1386290065-31813-2-git-send-email-srinivas.pandruvada@linux.intel.com>
On Thu, 5 Dec 2013, Srinivas Pandruvada wrote:
> Fix kernel warning and failure to register sensor hub devices with MFD.
> Now many devices has in-built sensor hubs. So by default this HID hub,
> is properly parsed and register individual sensors as platform device
> using MFD framework. But if a second sensor hub is attached via USB,
> which has same sensors, it will result in kernel warning and failure
> to register MFD cell as the platform device sysfs file name will be
> same as created by in-built sensor hubs. This patch sets MFD cell id
> to PLATFORM_DEVID_AUTO. In this way there will never
> be duplicate sysfs file names.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Applied, thanks Srinivas.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH 2/2] elantech: Add support for IC-body version 8
From: Hans de Goede @ 2013-12-09 14:32 UTC (permalink / raw)
To: linux-input; +Cc: Peter Hutterer, Hans de Goede
In-Reply-To: <1386599551-2339-1-git-send-email-hdegoede@redhat.com>
Acording to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1232877
a patch for this has been send before, but I don't see this in 3.13-rc3,
so here is another one.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/mouse/elantech.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index f7baa32..fc72446 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1350,6 +1350,7 @@ static int elantech_set_properties(struct elantech_data *etd)
break;
case 6:
case 7:
+ case 8:
etd->hw_version = 4;
break;
default:
--
1.8.4.2
^ permalink raw reply related
* [PATCH 1/2] elantech: Properly differentiate between clickpads and normal touchpads
From: Hans de Goede @ 2013-12-09 14:32 UTC (permalink / raw)
To: linux-input; +Cc: Peter Hutterer, Hans de Goede
The current assumption in the elantech driver that hw version 3 touchpads are
never clickpads and hw version 4 touchpads are always clickpads is wrong.
There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux
I've spend a couple of hours wading through various bugzillas,
launchpads and forum posts to create a list of fw-versions and capabilities
for different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.
Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the driver,
so that we've this info at hand if we need to revisit this later.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/mouse/elantech.c | 43 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 8551dca..f7baa32 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
unsigned char *packet = psmouse->packet;
input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+ input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
input_mt_report_pointer_emulation(dev, true);
input_sync(dev);
}
@@ -984,6 +985,42 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
}
/*
+ * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
+ * fw_version for this is based on the following fw_version & caps table:
+ *
+ * Laptop-model: fw_version: caps: buttons:
+ * Acer S3 0x461f00 10, 13, 0e clickpad
+ * Acer S7-392 0x581f01 50, 17, 0d clickpad
+ * Acer V5-131 0x461f02 01, 16, 0c clickpad
+ * Acer V5-551 0x461f00 ? clickpad
+ * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
+ * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
+ * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
+ * Asus UX31 0x361f00 20, 15, 0e clickpad
+ * Asus UX32VD 0x361f02 00, 15, 0e clickpad
+ * Avatar AVIU-145A2 0x361f00 ? clickpad
+ * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
+ * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
+ * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
+ * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
+ * Samsung NP900X3E-A02 0x575f03 ? clickpad
+ * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
+ * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
+ * Samsung RF710 0x450f00 ? 2 hw buttons
+ * System76 Pangolin 0x250f01 ? 2 hw buttons
+ * (*) + 3 trackpoint buttons
+ */
+static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
+{
+ struct input_dev *dev = psmouse->dev;
+ struct elantech_data *etd = psmouse->private;
+
+ if (etd->fw_version & 0x001000)
+ __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
+}
+
+/*
* Set the appropriate event bits for the input subsystem
*/
static int elantech_set_input_params(struct psmouse *psmouse)
@@ -1026,6 +1063,8 @@ static int elantech_set_input_params(struct psmouse *psmouse)
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
/* fall through */
case 3:
+ if (etd->hw_version == 3)
+ elantech_set_buttonpad_prop(psmouse);
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
input_set_abs_params(dev, ABS_Y, y_min, y_max, 0, 0);
if (etd->reports_pressure) {
@@ -1047,9 +1086,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
*/
psmouse_warn(psmouse, "couldn't query resolution data.\n");
}
- /* v4 is clickpad, with only one button. */
- __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
- __clear_bit(BTN_RIGHT, dev->keybit);
+ elantech_set_buttonpad_prop(psmouse);
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* For X to recognize me as touchpad. */
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
--
1.8.4.2
^ permalink raw reply related
* [PATCH] drivers/input/misc: new PC speaker sounds, clicks and notes
From: Karl Dahlke @ 2013-12-09 12:22 UTC (permalink / raw)
To: linux-input, linux-kernel
From: Karl Dahlke <eklhad@gmail.com>
The speaker driver can play a tone at a specified frequency,
or the standard control G bell,
which is a special case of TONE at 1000 hz 0.1 seconds.
This patch adds kd_mkpulse() to generate a soft click.
This is introduced to support accessibility modules and adapters in the future.
With this in place, a module can easily provide soft clicks,
i.e. audible feedback, whenever a key is depressed,
or when that keystroke is echoed on screen, whichever you prefer.
(Many people find the latter more valuable.)
This allows a blind user, for example, to have ongoing feedback while typing,
even if he is, at the same time, listening to text that is already on screen.
This is faster and more convenient than having characters echoed verbally.
And it works all the time, even if speech or braille is not working
for whatever reason. And there are many reasons those adapters could fail.
Misconfigured sound card, bad serial connection,
software synth not loading, etc.
Thus these forms of audio feedback are very important.
This should not be confused with the click function in certain specialized
keyboards such as lkkbd.c.
That function does a serio write to the client to activate clicks locally.
In contrast, this function generates a one-time pulse at the pc speaker,
or through a similar driver, so that modules can click whenever they want,
e.g. when a key is echoed back to you by a running application,
perhaps a thousand miles away over ssh, so you know all is well.
A module may want to click, or issue a series of clicks, for many reasons.
Another function introduced by this patch is kd_mknotes,
which plays a series of tones in the background.
You could do this yourself with kd_mksound and timers,
but why should everyone reinvent the wheel?
It is better to write the function once, properly, in the kernel,
and let modules use it thereafter.
Again, this is a means to an end.
Accessibility modules can generate rapid sequences of notes
to indicate various conditions, even error conditions,
especially if speech or braille is not working.
These notes may be the only feedback the user has to diagnose the problem.
Again, extremely valuable in a difficult situation.
This may be useful to other developers in other situations as well.
A third function kd_mksteps builds a chromatic scale,
from one frequency to another in steps.
This is a convenience on top of kd_mknotes.
The half-tone scale, with a step of 6%, starting at middle C, is approximately
kd_mksteps(260, 530, 6, 150);
Use a negative step for a descending scale.
Signed-off-by: Karl Dahlke <eklhad@gmail.com>
---
A few personal comments if I may.
I have tried for 15 years to get some of my work into the kernel,
without success.
That is partly understandable, because my early work was quite intrusive,
especially in 2.2 and 2.4,
and it was specifically one adapter, my adapter, and not a general approach.
So you were wise to say no.
But two years ago I redesigned everything,
so that almost all of my adapter runs in user space, and connects to the kernel
through a device driver.
The driver is not specific to my adapter, it supports any text based adapter
in any language (unicode).
It is a general approach, a much better design.
I asked, two years ago, if someone would help me usher these changes
into the 2.6 kernel, since Linux hacking is tremendously difficult,
even if you can see!
My ideas were well received, but the overall response was,
"This isn't a high priority for us."
That is a direct quote.
Needless to say this made me sad.
But not unexpected; accessibility has never been a priority
for Linux, or Microsoft, and Aple only gets half a nod for its VoiceOver.
There really are a lot of things vying for our atention, aren't there?
Well it's been two years and I thought I'd try again,
in the spirit of SubmittingPatches section 10, Don't Get Discouraged.
If this or subsequent patches cannot be applied as-is,
please work with me on this project,
don't just tell me to read chapter 17 of some 8,000 page manual.
I might really need some help from someone on the inside to make this fly.
It would be much appreciated.
Here is the first patch, enhancing sounds as described in the commit log above.
After this would come a supporting module, and then a device driver,
and that's it.
Well possibly one more patch for a notifier sleep function,
but I would have to discuss that one with you-all.
That one is a bit more complicated.
So this is the first step.
The code passes the style checker,
and has been exercised, in 3.12.3, by myself and others.
diff -uprN a/drivers/input/misc/pcspkr.c b/drivers/input/misc/pcspkr.c
--- a/drivers/input/misc/pcspkr.c 2013-12-08 19:02:31.000000000 -0500
+++ b/drivers/input/misc/pcspkr.c 2013-12-08 19:02:31.000000000 -0500
@@ -19,6 +19,8 @@
#include <linux/input.h>
#include <linux/platform_device.h>
#include <linux/timex.h>
+#include <linux/delay.h>
+
#include <asm/io.h>
MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
@@ -26,25 +28,26 @@ MODULE_DESCRIPTION("PC Speaker beeper dr
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:pcspkr");
-static int pcspkr_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
+/* Toggle the speaker, but not if a tone is sounding */
+static void speaker_toggle(void)
{
- unsigned int count = 0;
+ char c;
unsigned long flags;
- if (type != EV_SND)
- return -1;
-
- switch (code) {
- case SND_BELL: if (value) value = 1000;
- case SND_TONE: break;
- default: return -1;
+ raw_spin_lock_irqsave(&i8253_lock, flags);
+ c = inb_p(0x61);
+ if ((c&3) != 3) {
+ c &= 0xfe;
+ c ^= 2; /* toggle */
+ outb(c, 0x61);
}
+ raw_spin_unlock_irqrestore(&i8253_lock, flags);
+}
- if (value > 20 && value < 32767)
- count = PIT_TICK_RATE / value;
-
+static void speaker_sing(unsigned int count)
+{
+ unsigned long flags;
raw_spin_lock_irqsave(&i8253_lock, flags);
-
if (count) {
/* set command for counter 2, 2 byte write */
outb_p(0xB6, 0x43);
@@ -57,8 +60,44 @@ static int pcspkr_event(struct input_dev
/* disable counter 2 */
outb(inb_p(0x61) & 0xFC, 0x61);
}
-
raw_spin_unlock_irqrestore(&i8253_lock, flags);
+}
+
+static int pcspkr_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
+{
+ unsigned int count;
+
+ if (type != EV_SND)
+ return -1;
+
+ switch (code) {
+ case SND_BELL:
+ if (value)
+ value = 1000;
+ /* fall through */
+
+ case SND_TONE:
+ count = 0;
+ if (value > 20 && value < 32767)
+ count = PIT_TICK_RATE / value;
+ speaker_sing(count);
+ break;
+
+ case SND_PULSE:
+ /* Don't hold the cpu for more than 1ms */
+ /* no reason for a pulse to ever be longer than that. */
+ if (value > 1000)
+ value = 1000;
+ /* if a pulse is too short it can't be heard anyways. */
+ if (value < 20)
+ break;
+ speaker_toggle();
+ udelay(value);
+ speaker_toggle();
+ break;
+
+ default: return -1;
+ }
return 0;
}
@@ -81,7 +120,8 @@ static int pcspkr_probe(struct platform_
pcspkr_dev->dev.parent = &dev->dev;
pcspkr_dev->evbit[0] = BIT_MASK(EV_SND);
- pcspkr_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE);
+ pcspkr_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE) |
+ BIT_MASK(SND_PULSE);
pcspkr_dev->event = pcspkr_event;
err = input_register_device(pcspkr_dev);
diff -uprN a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
--- a/drivers/tty/vt/keyboard.c 2013-12-08 19:02:31.000000000 -0500
+++ b/drivers/tty/vt/keyboard.c 2013-12-08 19:02:31.000000000 -0500
@@ -261,6 +261,213 @@ void kd_mksound(unsigned int hz, unsigne
}
EXPORT_SYMBOL(kd_mksound);
+static int kd_pulse_helper(struct input_handle *handle, void *data)
+{
+ unsigned int *width = data;
+ struct input_dev *dev = handle->dev;
+
+ if (*width == 0)
+ return 0;
+
+ if (test_bit(EV_SND, dev->evbit)) {
+ if (test_bit(SND_PULSE, dev->sndbit)) {
+ input_inject_event(handle, EV_SND, SND_PULSE, *width);
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
+/* the width of the pulse is in microseconds, must be between 20 and 1000 */
+void kd_mkpulse(unsigned int width)
+{
+ input_handler_for_each_handle(&kbd_handler, &width, kd_pulse_helper);
+}
+EXPORT_SYMBOL(kd_mkpulse);
+
+/*
+ * Push notes onto a sound fifo and play them via an asynchronous thread.
+ * kd_mksound is a single tone, but kd_mknotes is a series of notes.
+ * this is used primarily by the accessibility modules, to sound
+ * various alerts and conditions for blind users.
+ * This is particularly helpful when the adapter is not working,
+ * for whatever reason. These functions are central to the kernel,
+ * and do not depend on sound cards, loadable modules, etc.
+ * These notes can also alert a system administrator to conditions
+ * that warrant immediate attention.
+ * Each note is specified by 2 shorts. The first is the frequency in hurtz,
+ * and the second is the duration in hundredths of a second.
+ * A frequency of -1 is a rest.
+ * A frequency of 0 ends the list of notes.
+ */
+
+#define SF_LEN 64 /* length of sound fifo */
+static short sf_fifo[SF_LEN];
+static int sf_head, sf_tail;
+static DEFINE_RAW_SPINLOCK(soundfifo_lock);
+
+/* Pop the next sound out of the sound fifo. */
+static void pop_soundfifo(unsigned long);
+static DEFINE_TIMER(kd_mknotes_timer, pop_soundfifo, 0, 0);
+static void pop_soundfifo(unsigned long notUsed)
+{
+ unsigned long flags;
+ int freq, duration;
+ int i;
+ long jifpause;
+
+ raw_spin_lock_irqsave(&soundfifo_lock, flags);
+
+ i = sf_tail;
+ if (i == sf_head) {
+ freq = 0;
+ duration = 0;
+ } else {
+ freq = sf_fifo[i];
+ duration = sf_fifo[i + 1];
+ i += 2;
+ if (i == SF_LEN)
+ i = 0;
+ sf_tail = i;
+ }
+
+ raw_spin_unlock_irqrestore(&soundfifo_lock, flags);
+
+ if (freq == 0) {
+ /* turn off singing speaker */
+ kd_nosound(0);
+ return;
+ }
+
+ jifpause = msecs_to_jiffies(duration);
+ /* not sure of the rounding, if duration < HZ */
+ if (jifpause == 0)
+ jifpause = 1;
+ mod_timer(&kd_mknotes_timer, jiffies + jifpause);
+
+ if (freq < 0) {
+ /* This is a rest between notes */
+ kd_nosound(0);
+ } else {
+ input_handler_for_each_handle(&kbd_handler, &freq,
+ kd_sound_helper);
+ }
+}
+
+/* Push a string of notes into the sound fifo. */
+void kd_mknotes(const short *p)
+{
+ int i;
+ bool wake = false;
+ unsigned long flags;
+
+ if (*p == 0)
+ return; /* empty list */
+
+ raw_spin_lock_irqsave(&soundfifo_lock, flags);
+
+ i = sf_head;
+ if (i == sf_tail)
+ wake = true;
+
+ /* Copy shorts into the fifo, until the terminating zero. */
+ while (*p) {
+ sf_fifo[i++] = *p++;
+ sf_fifo[i++] = (*p++) * 10;
+ if (i == SF_LEN)
+ i = 0; /* wrap around */
+ if (i == sf_tail) {
+ /* fifo is full */
+ goto done;
+ }
+ sf_head = i;
+ }
+
+ /* try to add on a rest, to carry the last note through */
+ sf_fifo[i++] = -1;
+ sf_fifo[i++] = 10;
+ if (i == SF_LEN)
+ i = 0; /* wrap around */
+ if (i != sf_tail)
+ sf_head = i;
+
+done:
+ raw_spin_unlock_irqrestore(&soundfifo_lock, flags);
+
+ /* first sound, get things started. */
+ if (wake)
+ pop_soundfifo(0);
+}
+EXPORT_SYMBOL(kd_mknotes);
+
+/* Push an ascending or descending sequence of notes into the sound fifo.
+ * Step is a geometric factor on frequency, increase by x percent.
+ * 100% goes up by octaves, -50% goes down by octaves.
+ * 12% is a wholetone scale, while 6% is a chromatic scale.
+ * Duration is in milliseconds, for very fast frequency sweeps. But this
+ * is based on jiffies timing, so is subject to the resolution of HZ. */
+void kd_mksteps(int f1, int f2, int step, int duration)
+{
+ int i;
+ bool wake = false;
+ unsigned long flags;
+
+ /* are the parameters in range? */
+ if (step != (char)step)
+ return;
+ if (duration <= 0 || duration > 2000)
+ return;
+ if (f1 < 50 || f1 > 8000)
+ return;
+ if (f2 < 50 || f2 > 8000)
+ return;
+
+ /* avoid infinite loops */
+ if (step == 0 ||
+ (f1 < f2 && step < 0) ||
+ (f1 > f2 && step > 0))
+ return;
+
+ raw_spin_lock_irqsave(&soundfifo_lock, flags);
+
+ i = sf_head;
+ if (i == sf_tail)
+ wake = true;
+
+ /* Copy shorts into the fifo, until start reaches end */
+ while ((step > 0 && f1 < f2) || (step < 0 && f1 > f2)) {
+ sf_fifo[i++] = f1;
+ sf_fifo[i++] = duration;
+ if (i == SF_LEN)
+ i = 0; /* wrap around */
+ if (i == sf_tail) {
+ /* fifo is full */
+ goto done;
+ }
+ sf_head = i;
+ f1 = f1 * (100+step) / 100;
+ if (f1 < 50 || f1 > 8000)
+ break;
+ }
+
+ /* try to add on a rest, to carry the last note through */
+ sf_fifo[i++] = -1;
+ sf_fifo[i++] = 10;
+ if (i == SF_LEN)
+ i = 0; /* wrap around */
+ if (i != sf_tail)
+ sf_head = i;
+
+done:
+ raw_spin_unlock_irqrestore(&soundfifo_lock, flags);
+
+ /* first sound, get things started. */
+ if (wake)
+ pop_soundfifo(0);
+}
+EXPORT_SYMBOL(kd_mksteps);
+
/*
* Setting the keyboard rate.
*/
diff -uprN a/include/linux/vt_kern.h b/include/linux/vt_kern.h
--- a/include/linux/vt_kern.h 2013-12-08 19:02:31.000000000 -0500
+++ b/include/linux/vt_kern.h 2013-12-08 19:02:31.000000000 -0500
@@ -28,6 +28,9 @@
#endif
extern void kd_mksound(unsigned int hz, unsigned int ticks);
+extern void kd_mkpulse(unsigned int width);
+extern void kd_mknotes(const short *p);
+extern void kd_mksteps(int freq1, int freq2, int step, int duration);
extern int kbd_rate(struct kbd_repeat *rep);
extern int fg_console, last_console, want_console;
diff -uprN a/include/uapi/linux/input.h b/include/uapi/linux/input.h
--- a/include/uapi/linux/input.h 2013-12-08 19:02:31.000000000 -0500
+++ b/include/uapi/linux/input.h 2013-12-08 19:02:31.000000000 -0500
@@ -906,6 +906,7 @@ struct input_keymap_entry {
#define SND_CLICK 0x00
#define SND_BELL 0x01
#define SND_TONE 0x02
+#define SND_PULSE 0x03
#define SND_MAX 0x07
#define SND_CNT (SND_MAX+1)
^ permalink raw reply
* [PATCH] drivers/input/misc/adxl34x: Fix bug in definition of ADXL346_2D_ORIENT
From: michael.hennerich @ 2013-12-09 11:35 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Michael Hennerich
From: Michael Hennerich <michael.hennerich@analog.com>
Coverity report pointet out by Dmitry
Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
drivers/input/misc/adxl34x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
index 0735de3..1cb1da2 100644
--- a/drivers/input/misc/adxl34x.c
+++ b/drivers/input/misc/adxl34x.c
@@ -158,7 +158,7 @@
/* ORIENT ADXL346 only */
#define ADXL346_2D_VALID (1 << 6)
-#define ADXL346_2D_ORIENT(x) (((x) & 0x3) >> 4)
+#define ADXL346_2D_ORIENT(x) (((x) & 0x30) >> 4)
#define ADXL346_3D_VALID (1 << 3)
#define ADXL346_3D_ORIENT(x) ((x) & 0x7)
#define ADXL346_2D_PORTRAIT_POS 0 /* +X */
--
1.7.9.5
^ permalink raw reply related
* Re: ADXL34X orientation definition
From: Dmitry Torokhov @ 2013-12-09 11:18 UTC (permalink / raw)
To: michael.hennerich; +Cc: linux-input@vger.kernel.org
In-Reply-To: <52A57B3A.7030607@analog.com>
On Monday, December 09, 2013 09:11:38 AM Michael Hennerich wrote:
> On 12/07/2013 10:53 AM, Dmitry Torokhov wrote:
> > Hi Michael,
> >
> > I was going though Coverity reports and it looks like definition of
> >
> > #define ADXL346_2D_ORIENT(x) (((x) & 0x3) >> 4)
> >
> > is not correct as it will always evaluate to 0. Should the mask be 0x30
> > instead?
> >
> > Thanks.
>
> Hi Dmitry,
>
> Good catch!
>
> Yes, of course - the mask should be 0x30.
> Shall I send a patch?
That would be great.
--
Dmitry
^ permalink raw reply
* Re: Sony DualShock4 - basic functions work, but looking to improve support
From: David Herrmann @ 2013-12-09 9:05 UTC (permalink / raw)
To: Simon Wood; +Cc: Linux Input, Antonio Ospite
In-Reply-To: <a26fde1f94cf430dd54a5045f82ac260.squirrel@mungewell.org>
Hi
On Mon, Dec 9, 2013 at 1:51 AM, <simon@mungewell.org> wrote:
> Following a very useful post on Reddit:
> http://np.reddit.com/r/PS4/comments/1p9y0l/pairing_your_ds4_controller_via_bluetooth/
>
> I was able to put the DS4 into discoverable mode, pair and connect using
> the 'hidd --connect 1C:66:6D:07:C3:E0' to get a working wireless/BT
> joystick.
>
> discoverable - hold 'PS' and 'Share' until light bar fast strobes.
> connected - light bar turns on constant.
> turn device off - hold 'PS' until light bar turns off.
>
> Not sure why, but under a bluetooth connection the 'hidraw0' device only
> outputs the first 10 bytes (compared to 64 bytes with USB connection)
> --
> $ hexdump -v -e '10/1 "%02x " "\n"' < /dev/hidraw0
> 01 7d 7e 82 7e 08 00 00 00 00
> 01 7d 7e 83 7e 08 00 00 00 00
> 01 7d 7e 81 7e 08 00 00 00 00
> 01 7d 7e 82 7e 08 00 00 00 00
> 01 7d 7e 80 7f 08 00 00 00 00
> --
>
> Attached are some bluetooth details for the device. No idea on how to get
> audio to/from the device - I was kind of hoping it would behave like a BT
> headset.
Regarding Bluetooth: hidd is deprecated. It should be all handled by
bluetoothd now. But once it's connected, HIDP is handled by the kernel
so this shouldn't be an issue here.
The SDP/hcitool information are pretty sparse so they won't help much.
All they tell is that the device uses HIDP (and a bit about BT
internals). No A2DP or alike. I guess sound is transmitted through the
HIDP channel (which is also what the wiimote does) and allows the same
transmission via USB and BT.
The report descriptor actually describes a lot more report-IDs than
just "0x01" which you describe in hidraw.txt. Are you sure the
report-descriptors are the same for USB and BT? 64bytes also seems
quite large for HID reports, I thought BT had a limit of 22 (but I'm
not sure). At least your report-descriptor says the biggest report is
63 bytes so that seems to be right for USB at least. You could turn on
BT debugging, the HIDP layer will then print size/content information
for incoming L2CAP skbs. This should help finding the culprit.
Thanks
David
^ permalink raw reply
* Re: ADXL34X orientation definition
From: Michael Hennerich @ 2013-12-09 8:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <20131207095335.GA10573@core.coreip.homeip.net>
On 12/07/2013 10:53 AM, Dmitry Torokhov wrote:
> Hi Michael,
>
> I was going though Coverity reports and it looks like definition of
>
> #define ADXL346_2D_ORIENT(x) (((x) & 0x3) >> 4)
>
> is not correct as it will always evaluate to 0. Should the mask be 0x30
> instead?
>
> Thanks.
>
Hi Dmitry,
Good catch!
Yes, of course - the mask should be 0x30.
Shall I send a patch?
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
^ permalink raw reply
* Re: [PATCH] Input: samsung-keypad - favor platform data if present
From: Jingoo Han @ 2013-12-09 8:04 UTC (permalink / raw)
To: 'Dmitry Torokhov', linux-input
Cc: 'Sachin Kamat', 'Thomas Abraham',
'Joonyoung Shim', linux-kernel, 'Jingoo Han'
In-Reply-To: <20131206100215.GA27763@core.coreip.homeip.net>
On Friday, December 06, 2013 7:02 PM, Dmitry Torokhov wrote:
>
> We should be able to override firmware-provided parameters with in-kernel
> data, if needed. To that effect favor platform data, if present, over
> devicetree data.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
It looks good.
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/input/keyboard/samsung-keypad.c | 36 +++++++++++++++++++--------------
> 1 file changed, 21 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH] Add: (1) Detection for newer Elantech touchpads, so that kernel doesn't fall-back to default PS/2 driver. (2) Enable hardware version 4 touchpad right click function.
From: Dmitry Torokhov @ 2013-12-09 6:32 UTC (permalink / raw)
To: Duson Lin; +Cc: linux-kernel, linux-input
In-Reply-To: <1386557990-27445-1-git-send-email-dusonlin@emc.com.tw>
Hi Duson.
On Mon, Dec 09, 2013 at 10:59:50AM +0800, Duson Lin wrote:
> Modify:
> (1) crc_enabled only support for v3 and v4 touchpad, so initialize crc_enabled as false first and
> check this hardware flag when hw_version as 3 or 4.
It looks to me there are several fixes rolled up together in this patch:
1. Support for the new hardware signatures (8 and 10, although I already
applied patch for 8)
2. Fix to handle CRC check
3. Changes to report BTN_RIGHT.
Could you please split them up please?
Also, I am not sure if we can simply start reporting BTN_RIGHT as
present, even on devices that don't actually have the right button, as
this will interfere with userspace providing emulation for multiple
buttons.
Is it possible to determine if a given model had right button or not?
Thanks.
>
> Signed-off-by: Duson Lin <dusonlin@emc.com.tw>
> ---
> drivers/input/mouse/elantech.c | 30 ++++++++++++++----------------
> drivers/input/mouse/elantech.h | 2 +-
> 2 files changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 8551dca..b3627cf 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1,5 +1,5 @@
> /*
> - * Elantech Touchpad driver (v6)
> + * Elantech Touchpad driver (v7)
> *
> * Copyright (C) 2007-2009 Arjan Opmeer <arjan@opmeer.net>
> *
> @@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
> unsigned char *packet = psmouse->packet;
>
> input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
> + input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
> input_mt_report_pointer_emulation(dev, true);
> input_sync(dev);
> }
> @@ -1047,9 +1048,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
> */
> psmouse_warn(psmouse, "couldn't query resolution data.\n");
> }
> - /* v4 is clickpad, with only one button. */
> __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
> - __clear_bit(BTN_RIGHT, dev->keybit);
> __set_bit(BTN_TOOL_QUADTAP, dev->keybit);
> /* For X to recognize me as touchpad. */
> input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
> @@ -1186,19 +1185,12 @@ static struct attribute_group elantech_attr_group = {
>
> static bool elantech_is_signature_valid(const unsigned char *param)
> {
> - static const unsigned char rates[] = { 200, 100, 80, 60, 40, 20, 10 };
> - int i;
> -
> if (param[0] == 0)
> return false;
>
> if (param[1] == 0)
> return true;
>
> - for (i = 0; i < ARRAY_SIZE(rates); i++)
> - if (param[2] == rates[i])
> - return false;
> -
> return true;
> }
>
> @@ -1298,6 +1290,14 @@ static int elantech_set_properties(struct elantech_data *etd)
> {
> /* This represents the version of IC body. */
> int ver = (etd->fw_version & 0x0f0000) >> 16;
> + /*
> + * The signatures of v3 and v4 packets change depending on the
> + * value of this hardware flag. But the v1 and v2 have not crc
> + * check mechanism and the same hardware flag are also defined
> + * as other function. So crc_enabled must be initialized as false
> + * first and checking by different hw_version.
> + */
> + etd->crc_enabled = false;
>
> /* Early version of Elan touchpads doesn't obey the rule. */
> if (etd->fw_version < 0x020030 || etd->fw_version == 0x020600)
> @@ -1309,10 +1309,14 @@ static int elantech_set_properties(struct elantech_data *etd)
> etd->hw_version = 2;
> break;
> case 5:
> + etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
> etd->hw_version = 3;
> break;
> case 6:
> case 7:
> + case 8:
> + case 10:
> + etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
> etd->hw_version = 4;
> break;
> default:
> @@ -1343,12 +1347,6 @@ static int elantech_set_properties(struct elantech_data *etd)
> etd->reports_pressure = true;
> }
>
> - /*
> - * The signatures of v3 and v4 packets change depending on the
> - * value of this hardware flag.
> - */
> - etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
> -
> return 0;
> }
>
> diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
> index 036a04a..c963ac8 100644
> --- a/drivers/input/mouse/elantech.h
> +++ b/drivers/input/mouse/elantech.h
> @@ -1,5 +1,5 @@
> /*
> - * Elantech Touchpad driver (v6)
> + * Elantech Touchpad driver (v7)
> *
> * Copyright (C) 2007-2009 Arjan Opmeer <arjan@opmeer.net>
> *
> --
> 1.7.10.4
>
--
Dmitry
^ permalink raw reply
* [PATCH] Add: (1) Detection for newer Elantech touchpads, so that kernel doesn't fall-back to default PS/2 driver. (2) Enable hardware version 4 touchpad right click function.
From: Duson Lin @ 2013-12-09 2:59 UTC (permalink / raw)
To: linux-kernel, linux-input, dmitry.torokhov; +Cc: Duson Lin
Modify:
(1) crc_enabled only support for v3 and v4 touchpad, so initialize crc_enabled as false first and
check this hardware flag when hw_version as 3 or 4.
Signed-off-by: Duson Lin <dusonlin@emc.com.tw>
---
drivers/input/mouse/elantech.c | 30 ++++++++++++++----------------
drivers/input/mouse/elantech.h | 2 +-
2 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 8551dca..b3627cf 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1,5 +1,5 @@
/*
- * Elantech Touchpad driver (v6)
+ * Elantech Touchpad driver (v7)
*
* Copyright (C) 2007-2009 Arjan Opmeer <arjan@opmeer.net>
*
@@ -486,6 +486,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
unsigned char *packet = psmouse->packet;
input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+ input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
input_mt_report_pointer_emulation(dev, true);
input_sync(dev);
}
@@ -1047,9 +1048,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
*/
psmouse_warn(psmouse, "couldn't query resolution data.\n");
}
- /* v4 is clickpad, with only one button. */
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
- __clear_bit(BTN_RIGHT, dev->keybit);
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
/* For X to recognize me as touchpad. */
input_set_abs_params(dev, ABS_X, x_min, x_max, 0, 0);
@@ -1186,19 +1185,12 @@ static struct attribute_group elantech_attr_group = {
static bool elantech_is_signature_valid(const unsigned char *param)
{
- static const unsigned char rates[] = { 200, 100, 80, 60, 40, 20, 10 };
- int i;
-
if (param[0] == 0)
return false;
if (param[1] == 0)
return true;
- for (i = 0; i < ARRAY_SIZE(rates); i++)
- if (param[2] == rates[i])
- return false;
-
return true;
}
@@ -1298,6 +1290,14 @@ static int elantech_set_properties(struct elantech_data *etd)
{
/* This represents the version of IC body. */
int ver = (etd->fw_version & 0x0f0000) >> 16;
+ /*
+ * The signatures of v3 and v4 packets change depending on the
+ * value of this hardware flag. But the v1 and v2 have not crc
+ * check mechanism and the same hardware flag are also defined
+ * as other function. So crc_enabled must be initialized as false
+ * first and checking by different hw_version.
+ */
+ etd->crc_enabled = false;
/* Early version of Elan touchpads doesn't obey the rule. */
if (etd->fw_version < 0x020030 || etd->fw_version == 0x020600)
@@ -1309,10 +1309,14 @@ static int elantech_set_properties(struct elantech_data *etd)
etd->hw_version = 2;
break;
case 5:
+ etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
etd->hw_version = 3;
break;
case 6:
case 7:
+ case 8:
+ case 10:
+ etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
etd->hw_version = 4;
break;
default:
@@ -1343,12 +1347,6 @@ static int elantech_set_properties(struct elantech_data *etd)
etd->reports_pressure = true;
}
- /*
- * The signatures of v3 and v4 packets change depending on the
- * value of this hardware flag.
- */
- etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
-
return 0;
}
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 036a04a..c963ac8 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -1,5 +1,5 @@
/*
- * Elantech Touchpad driver (v6)
+ * Elantech Touchpad driver (v7)
*
* Copyright (C) 2007-2009 Arjan Opmeer <arjan@opmeer.net>
*
--
1.7.10.4
^ permalink raw reply related
* Re: Sony DualShock4 - basic functions work, but looking to improve support
From: simon @ 2013-12-09 0:51 UTC (permalink / raw)
To: simon; +Cc: Linux Input, Antonio Ospite
In-Reply-To: <61a33717137a02a1d0eac5a2d1cb257e.squirrel@mungewell.org>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
Following a very useful post on Reddit:
http://np.reddit.com/r/PS4/comments/1p9y0l/pairing_your_ds4_controller_via_bluetooth/
I was able to put the DS4 into discoverable mode, pair and connect using
the 'hidd --connect 1C:66:6D:07:C3:E0' to get a working wireless/BT
joystick.
discoverable - hold 'PS' and 'Share' until light bar fast strobes.
connected - light bar turns on constant.
turn device off - hold 'PS' until light bar turns off.
Not sure why, but under a bluetooth connection the 'hidraw0' device only
outputs the first 10 bytes (compared to 64 bytes with USB connection)
--
$ hexdump -v -e '10/1 "%02x " "\n"' < /dev/hidraw0
01 7d 7e 82 7e 08 00 00 00 00
01 7d 7e 83 7e 08 00 00 00 00
01 7d 7e 81 7e 08 00 00 00 00
01 7d 7e 82 7e 08 00 00 00 00
01 7d 7e 80 7f 08 00 00 00 00
--
Attached are some bluetooth details for the device. No idea on how to get
audio to/from the device - I was kind of hoping it would behave like a BT
headset.
Simon
[-- Attachment #2: hcitool_info.txt --]
[-- Type: text/plain, Size: 1017 bytes --]
simon@womble:~$ hcitool info 1C:66:6D:07:C3:E0
Requesting information ...
BD Address: 1C:66:6D:07:C3:E0
Device Name: Wireless Controller
LMP Version: 3.0 (0x5) LMP Subversion: 0x0
Manufacturer: Atheros Communications, Inc. (69)
Features: 0xff 0xfe 0x0d 0xfe 0x98 0x7f 0x79 0x87
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
<transparent SCO> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
<enhanced iscan> <interlaced iscan> <interlaced pscan>
<inquiry with RSSI> <extended SCO> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<sniff subrating> <pause encryption> <AFH cap. master>
<AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps>
<extended inquiry> <simple pairing> <encapsulated PDU>
<err. data report> <non-flush flag> <LSTO> <inquiry TX power>
<EPC> <extended features>
[-- Attachment #3: sdptool_records.txt --]
[-- Type: text/plain, Size: 736 bytes --]
simon@womble:~/dualshock4$ sdptool records 1C:66:6D:07:C3:E0
Service Name: Wireless Controller
Service Description: Game Controller
Service Provider: Sony Computer Entertainment
Service RecHandle: 0x10001
Service Class ID List:
"Human Interface Device" (0x1124)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 17
"HIDP" (0x0011)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Human Interface Device" (0x1124)
Version: 0x0100
Service RecHandle: 0x10002
Service Class ID List:
"PnP Information" (0x1200)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Profile Descriptor List:
"PnP Information" (0x1200)
Version: 0x0103
^ permalink raw reply
* Re: [PATCH] input synaptics-rmi4: elliminate multiple sensor support from rmi_f11.c
From: Christopher Heiny @ 2013-12-09 0:11 UTC (permalink / raw)
To: Andrew Duggan
Cc: Dmitry Torokhov, Linux Input, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij,
Benjamin Tissoires
In-Reply-To: <1386295167-866-1-git-send-email-aduggan@synaptics.com>
On 12/05/2013 05:59 PM, Andrew Duggan wrote:
> This patch implements changes to the synaptics-rmi4 branch of
> Dmitry's input tree. The base for the patch is commit
> 8ca01dc61a42b6f7bcba052a8c084000f7057a34.
>
> This patch elliminates support for multiple sensors in rmi_f11. This feature
> has been removed from the RMI4 spec and no devices have every used multiple
> F11 sensors on a single device.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Sign-off-by: Christopher Heiny <cheiny@synaptics.com>
^ permalink raw reply
* Re: [PATCH] input synaptics-rmi4: elliminate multiple sensor support from rmi_f11.c
From: Christopher Heiny @ 2013-12-09 0:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Duggan, Linux Input, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij,
Benjamin Tissoires
In-Reply-To: <20131207160527.GB11635@core.coreip.homeip.net>
On 12/07/2013 08:05 AM, Dmitry Torokhov wrote:
> Hi Andrew,
>
> On Thu, Dec 05, 2013 at 05:59:27PM -0800, Andrew Duggan wrote:
>> > This patch implements changes to the synaptics-rmi4 branch of
>> > Dmitry's input tree. The base for the patch is commit
>> > 8ca01dc61a42b6f7bcba052a8c084000f7057a34.
>> >
>> > This patch elliminates support for multiple sensors in rmi_f11. This feature
>> > has been removed from the RMI4 spec and no devices have every used multiple
>> > F11 sensors on a single device.
>> >
>> > Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> I am a bit confused here - has this been coordinated with recent
> submission by Chris? I'd prefer if there was a single person from
> Synaptics posting patches at the same time, so that I know they are
> properly sequenced.
Hi,
To make things go faster, Andrew working with me to split the large
patch into manageable bites, and I asked him to go ahead and submit that
one. That patch is in sequence - I'll sign off on it in a moment.
We'll run future patches through my email.
Chris
^ 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