* Re: [PATCH hisi] Input: i2c_atmel_read() can be static
From: zhangfei @ 2014-12-21 11:29 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Dmitry Torokhov, linux-input, linux-kernel, xuwei (O)
In-Reply-To: <20141219015659.GA49367@snb.sh.intel.com>
On 12/19/2014 09:56 AM, kbuild test robot wrote:
> drivers/input/touchscreen/atmel_mXT224E.c:460:5: sparse: symbol 'i2c_atmel_read' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:496:5: sparse: symbol 'i2c_atmel_write' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:532:5: sparse: symbol 'i2c_atmel_write_byte_data' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:538:10: sparse: symbol 'get_object_address' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:547:9: sparse: symbol 'get_object_size' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:557:9: sparse: symbol 'get_object_size_from_address' was not declared. Should it be static?
> drivers/input/touchscreen/atmel_mXT224E.c:847:32: sparse: symbol 'atmel_ts_get_pdata' was not declared. Should it be static?
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Thanks Fengguang for the patch, will take it.
However, the file drivers/input/touchscreen/atmel_mXT224E.c is not used
for mainline kernel.
Xuwei will remove git://github.com/hisilicon/linux-hisi
integration-hilt-linux-linaro.
Sorry for the confusion.
Thanks
^ permalink raw reply
* RE: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dudley Du @ 2014-12-22 2:09 UTC (permalink / raw)
To: Dmitry Torokhov, Jeremiah Mahler, rydberg@euromail.se,
bleung@google.com, David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20141220073154.GB4637@dtor-ws>
Thanks, Dmitry and Jeremiah,
I reproduced this issue in my side when putting fingers on trackpad when system booting up.
It only happened on gen3 trackpad device.
The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not set, so when cyapa->input is not set,
the interrupt process should be passed, but since the logica error, it's not, so this issue happen.
The fix code should be as below.
I will correct it and resubmited the patches.
Code to fix this issue.
@@ -585,9 +585,10 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
/* Interrupt event maybe from trackpad device input reporting. */
if (cont && cyapa->ops->irq_handler) {
/* Still in probling or in firware image udpating or reading. */
- if (!cyapa->input && cyapa->ops->sort_empty_output_data) {
- cyapa->ops->sort_empty_output_data(cyapa,
- NULL, NULL, NULL);
+ if (!cyapa->input) {
+ if (cyapa->ops->sort_empty_output_data)
+ cyapa->ops->sort_empty_output_data(cyapa,
+ NULL, NULL, NULL);
goto out;
}
Thanks,
Dudley
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: 2014?12?20? 15:32
> To: Jeremiah Mahler; Dudley Du; rydberg@euromail.se; bleung@google.com;
> David Solda; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
>
> On Fri, Dec 19, 2014 at 11:15:33PM -0800, Jeremiah Mahler wrote:
> > Dudley,
> >
> > On Thu, Dec 18, 2014 at 06:00:44PM +0800, Dudley Du wrote:
> > > V16 patches have below updates, details of other updates see history list:
> > [...]
> >
> > This version has problems. I am getting an oops (below) and then things
> > quit working and usually my machine hangs.
> >
> > [ 2.388284] input: HDA Intel PCH Headphone as
> /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
> > [ 2.412938] FS-Cache: Netfs 'nfs' registered for caching
> > [ 2.427645] [drm] Initialized i915 1.6.0 20141121 for 0000:00:02.0 on minor 0
> > [ 2.428320] __add_probed_i2c_device failed to register device 1-4a
> > [ 2.428331] platform chromeos_laptop: Driver chromeos_laptop requests
> probe deferral
> > [ 2.429126] fbcon: inteldrmfb (fb0) is primary device
> > [ 2.449066] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000160
> > [ 2.449073] IP: [<ffffffff813f7b2b>] input_mt_sync_frame+0xb/0x60
>
> Sounds like we got an interrupts before we had a chance to initialize
> input device...
>
> Thanks.
>
> --
> Dmitry
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.
^ permalink raw reply
* Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dmitry Torokhov @ 2014-12-22 2:39 UTC (permalink / raw)
To: Dudley Du
Cc: Jeremiah Mahler, rydberg@euromail.se, bleung@google.com,
David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <BN1PR06MB0701C428956C2E7F7A1DD76D1560@BN1PR06MB070.namprd06.prod.outlook.com>
Hi Dudley,
On Mon, Dec 22, 2014 at 02:09:36AM +0000, Dudley Du wrote:
> Thanks, Dmitry and Jeremiah,
>
> I reproduced this issue in my side when putting fingers on trackpad when system booting up.
> It only happened on gen3 trackpad device.
> The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not set, so when cyapa->input is not set,
> the interrupt process should be passed, but since the logica error, it's not, so this issue happen.
>
> The fix code should be as below.
> I will correct it and resubmited the patches.
Please hold off resubmitting the patches just yet, let me go over the
last version you posted.
Thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] input: Add new sun4i-lradc-keys driver
From: Dmitry Torokhov @ 2014-12-22 2:51 UTC (permalink / raw)
To: Hans de Goede
Cc: Maxime Ripard, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <54955315.3030603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sat, Dec 20, 2014 at 11:44:37AM +0100, Hans de Goede wrote:
> Hi Dmitry,
>
> On 18-12-14 18:51, Dmitry Torokhov wrote:
> >Hi Hans,
> >
> >On Thu, Dec 18, 2014 at 11:23:13AM +0100, Hans de Goede wrote:
> >>Allwinnner sunxi SoCs have a low resolution adc (called lradc) which is
> >>specifically designed to have various (tablet) keys (ie home, back, search,
> >>etc). attached to it using a resistor network. This adds a driver for this.
> >>
> >>There are 2 channels, currently this driver only supports chan0 since there
> >>are no boards known to use chan1.
> >>
> >>This has been tested on an olimex a10s-olinuxino-micro, a13-olinuxino, and
> >>a20-olinuxino-micro.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>--
> >>Changes in v2:
> >>-Change devicetree bindings to use a per key subnode, like gpio-keys does
> >>Changes in v3:
> >>-Handle keyup irq flag before irqdown, in case we get both at once
> >
> >Thank you for making changes. Can you please tell me if the driver still
> >works if you drop the patch below on top of it? The changes are:
> >
> >- split DT parsing into a separate function;
> >- make sure keymap is not empty;
> >- change 'ret' variable to 'error';
>
> The proposed changes look good, and I've given them a test-spin and everything
> still works fine.
Excellent, folded and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dudley Du @ 2014-12-22 2:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jeremiah Mahler, rydberg@euromail.se, bleung@google.com,
David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20141222023959.GA30082@dtor-ws>
Got it.
Thanks, Dmitry.
Dudley
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: 2014?12?22? 10:40
> To: Dudley Du
> Cc: Jeremiah Mahler; rydberg@euromail.se; bleung@google.com; David Solda;
> linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
>
> Hi Dudley,
>
> On Mon, Dec 22, 2014 at 02:09:36AM +0000, Dudley Du wrote:
> > Thanks, Dmitry and Jeremiah,
> >
> > I reproduced this issue in my side when putting fingers on trackpad when system
> booting up.
> > It only happened on gen3 trackpad device.
> > The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not
> set, so when cyapa->input is not set,
> > the interrupt process should be passed, but since the logica error, it's not, so this
> issue happen.
> >
> > The fix code should be as below.
> > I will correct it and resubmited the patches.
>
> Please hold off resubmitting the patches just yet, let me go over the
> last version you posted.
>
> Thanks!
>
>
> --
> Dmitry
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.
^ permalink raw reply
* Re: randconfig build error with next-20141219, in drivers/input/misc/regulator-haptic.c
From: Dmitry Torokhov @ 2014-12-22 3:02 UTC (permalink / raw)
To: Jim Davis
Cc: Stephen Rothwell, linux-next, linux-kernel, linux-input,
Grant Likely, Rob Herring
In-Reply-To: <CA+r1Zhh3u_JMnvvYaXD81ew--H_t9exuX-xvuNw8n=OPA-PWNA@mail.gmail.com>
On Fri, Dec 19, 2014 at 09:13:02AM -0700, Jim Davis wrote:
> Building with the attached random configuration file,
>
> drivers/input/misc/regulator-haptic.c: In function ‘regulator_haptic_probe’:
> drivers/input/misc/regulator-haptic.c:184:2: error: implicit
> declaration of function ‘devm_regulator_get_exclusive’
> [-Werror=implicit-function-declaration]
> haptic->regulator = devm_regulator_get_exclusive(&pdev->dev, "haptic");
> ^
> drivers/input/misc/regulator-haptic.c:184:20: warning: assignment makes pointer
> from integer without a cast [enabled by default]
> haptic->regulator = devm_regulator_get_exclusive(&pdev->dev, "haptic");
> ^
> cc1: some warnings being treated as errors
> make[3]: *** [drivers/input/misc/regulator-haptic.o] Error 1
Thanks, I'll add the missing dependency on CONFIG_REGULATOR.
--
Dmitry
^ permalink raw reply
* Re: [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
From: Vishnu Patekar @ 2014-12-22 3:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Hans de Goede, mark.rutland@arm.com, devicetree@vger.kernel.org,
jdelvare@suse.de, linux@arm.linux.org.uk, pawel.moll@arm.com,
ijc+devicetree@hellion.org.uk, benh@kernel.crashing.org,
Dmitry Torokhov, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, robh+dt@kernel.org, msalter@redhat.com,
linux-input@vger.kernel.org, Grant Likely, Kumar Gala,
maxime.ripard@free-electrons.com, linux-arm-kernel
In-Reply-To: <CAGb2v659jEj7cxPCu1UNPb-p6iaH6Sjcp4LCgsBOyBh-odSUhw@mail.gmail.com>
Sorry for delayed response.
Thanks, Chen-Yu.
So, I'll keep ps2 enabled for Lime2 board without any comment.
On Mon, Dec 15, 2014 at 9:11 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi,
>
> On Mon, Dec 15, 2014 at 11:13 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 15-12-14 15:13, Vishnu Patekar wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Dec 14, 2014 at 2:31 PM, Hans de Goede <hdegoede@redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 13-12-14 21:01, Vishnu Patekar wrote:
>>>>>
>>>>>
>>>>> Hello Hans,
>>>>> Please find my comments inlined.
>>>>>
>>>>> On 12/13/14, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi VishnuPatekar,
>>>>>>
>>>>>> The patch mangling for this set seems to have gone a bit wrong I'm
>>>>>> afraid
>>>>>
>>>>>
>>>>>
>>>>> No, this time I've corrected it. Infact, last version of patch did not
>>>>> used the status bit error macros.
>>>>>
>>>>>> a lot of the patches have my fixup commit messages (which should have
>>>>>> disappeared when squashing in the patches), please replace those by
>>>>>> proper
>>>>>> commit messages describing what the patch actually does.
>>>>>
>>>>>
>>>>> Yes, [PATCHv3 3/5] uses fixup. I'll correct it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Also the adding of the commented nodes for the lime2 seems to be gone
>>>>>> entirely
>>>>>> from the set, instead now only a comment about the conflict with the
>>>>>> hdmi
>>>>>> pins is added, but it is above the i2c node instead of above a ps2
>>>>>> node.
>>>>>>
>>>>> Maxime's suggested that we should not add commented nodes specially
>>>>> when its trivial to apply. And just note saying ps20 pins conflict
>>>>> with HDMI.
>>>>
>>>>
>>>>
>>>> Ah, I see.
>>>>
>>>>> Should I remove the this comment as well?
>>>>> Or
>>>>> Put this note in start of DTS file?
>>>>
>>>>
>>>>
>>>> The comment should be added to where the pinctrl bits are, not to the
>>>> lime2
>>>> file, ps0 will conflict with hdmi on all boards.
>>>
>>>
>>> Well, In that case,PS2_0 pins conflicts with HDMI, PS2_1 pins
>>> conflicts with LCD. Every pin has multiplexing.
>>
>>
>> Almost every A10 board has a hdmi connector, and only the hdmi ddc pins
>> are multiplexed, so this is sort of special, but yes if we do not have
>> the commented nodes in the dts file, then this comment can be dropped too
>> I guess.
>
> All the HDMI pins have dedicated pins. In addition, the DDC pins are
> multiplexed. On the Lime, the dedicated pins (ball # R23, R22) are
> used. I just checked the schematics. There should be no conflict.
>
> ChenYu
^ permalink raw reply
* [PATCH] Input: regulator-haptic: Make regulator_haptic_set_voltage call regulator_haptic_toggle
From: Axel Lin @ 2014-12-22 4:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Pankaj Dubey, Chanwoo Choi, Hyunhee Kim, Kyungmin Park,
Jaewon Kim, linux-input
All the use cases in this driver has a regulator_haptic_toggle() call after
regulator_haptic_set_voltage(). So make regulator_haptic_set_voltage() call
regulator_haptic_toggle() to simplify the code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/input/misc/regulator-haptic.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c
index 9426221..5b18de3 100644
--- a/drivers/input/misc/regulator-haptic.c
+++ b/drivers/input/misc/regulator-haptic.c
@@ -76,6 +76,8 @@ static int regulator_haptic_set_voltage(struct regulator_haptic *haptic,
return error;
}
+ regulator_haptic_toggle(haptic, !!magnitude);
+
return 0;
}
@@ -84,7 +86,6 @@ static void regulator_haptic_work(struct work_struct *work)
struct regulator_haptic *haptic = container_of(work,
struct regulator_haptic, work);
unsigned int magnitude;
- int error;
mutex_lock(&haptic->mutex);
@@ -93,12 +94,7 @@ static void regulator_haptic_work(struct work_struct *work)
magnitude = ACCESS_ONCE(haptic->magnitude);
- error = regulator_haptic_set_voltage(haptic, magnitude);
- if (error)
- goto out;
-
- regulator_haptic_toggle(haptic, magnitude != 0);
-
+ regulator_haptic_set_voltage(haptic, magnitude);
out:
mutex_unlock(&haptic->mutex);
}
@@ -123,7 +119,6 @@ static void regulator_haptic_close(struct input_dev *input)
cancel_work_sync(&haptic->work);
regulator_haptic_set_voltage(haptic, 0);
- regulator_haptic_toggle(haptic, false);
}
static int __maybe_unused
@@ -225,7 +220,6 @@ static int __maybe_unused regulator_haptic_suspend(struct device *dev)
return error;
regulator_haptic_set_voltage(haptic, 0);
- regulator_haptic_toggle(haptic, false);
haptic->suspended = true;
@@ -245,10 +239,8 @@ static int __maybe_unused regulator_haptic_resume(struct device *dev)
haptic->suspended = false;
magnitude = ACCESS_ONCE(haptic->magnitude);
- if (magnitude) {
+ if (magnitude)
regulator_haptic_set_voltage(haptic, magnitude);
- regulator_haptic_toggle(haptic, true);
- }
mutex_unlock(&haptic->mutex);
--
1.9.1
^ permalink raw reply related
* [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-22 13:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: anshul.g@samsung.com, linux-input
Dear Mr. Dmitry and Linux Community,
I am Anshul Garg working on Linux Kernel from last 2 years .
I have one query regarding event filter mechanism in input subsystem.
Can you please help in answering my query as below:
=====================================================
In function input_pass_values in input.c file , input core sends all
events to each handler associated with
the input device ,
rcu_read_lock();
handle = rcu_dereference(dev->grab);
if (handle) {
count = input_to_handler(handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open)
count = input_to_handler(handle, vals, count);
}
after this in input_to_handler function events are filtered and sent
to the handler.
for (v = vals; v != vals + count; v++) {
if (handler->filter &&
handler->filter(handle, v->type, v->code, v->value))
continue;
if (end != v)
*end = *v;
end++;
}
But as per previous event filter mechanism all the events should be
parsed from all
handlers after that remaining events should be sent to handlers list.
And in comments also its mentioned as
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles.*/
So current approach to filter events seems to be incorrect.
Please help to clarify my query.
I have prepared one patch with new event filter mechanism which will
first filter all events from attached handlers then pass the remaining
events after being filtered
through all handlers unlike current implementation.
Once My query is resolved , I will send the patch.
Thanks
Anshul Garg
+91-9899777351
^ permalink raw reply
* Re: [PATCH 1/3] HID: rmi: Support non rmi devices by passing events to hid-input
From: Jiri Kosina @ 2014-12-22 13:24 UTC (permalink / raw)
To: Andrew Duggan; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <1419029143-20484-1-git-send-email-aduggan@synaptics.com>
On Fri, 19 Dec 2014, Andrew Duggan wrote:
> Allowing hid-rmi to bind to non rmi devices allows us to support composite USB
> devices which contain several HID devices one of which is a HID touchpad.
> Since all of the devices have the same VID and PID we can add the device
> to the hid_have_special_driver list and have hid-rmi handle all of the devices.
> Then hid-rmi's probe can look for the rmi specific HID report IDs and decide if
> it should handle the device as a rmi device or simply report that the events
> needs additional processing.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
> This patch series is my second attempt at getting the hid-rmi driver working on
> the Razer Blade 14 based on Benjamin's comments. I decided to break it up into
> three separate patches. This one allows hid-rmi to bind to all of the devices.
> Instead of adding a quirk I just look at the report IDs to see if it should
> do rmi or not.
I have now applied 1/3, and waiting for v2 once you sort out with Benjamin
the comments he had.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHv4 1/1] HID: add BETOP game controller force feedback support
From: Jiri Kosina @ 2014-12-22 13:43 UTC (permalink / raw)
To: Huang Bo; +Cc: linux-input, linux-kernel
In-Reply-To: <547D54FC.3080202@163.com>
On Tue, 2 Dec 2014, Huang Bo wrote:
> From: Huang Bo <huangbobupt@163.com>
>
> Adds force feedback support for BETOP USB game controllers.
> These devices are mass produced in China.
>
> Signed-off-by: Huang Bo <huangbobupt@163.com>
Applied to for-3.20/betop.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [RFC PATCH 0/2] USB: input: yealink.c: update key mappings
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov; +Cc: usbb2k-api-dev, linux-input, linux-kernel
Hello,
I have an Yealink USB phone which is handled by the yealink.c driver but the
'#' key returns an unexpected value and keys labeled "RING" and "MUTE" do not
return any value to userspace.
In the first patch of this series I replace the combination KEY_LEFTSHIFT and
KEY_3 with KEY_NUMERIC_POUND and I also replace other keys for internal consistency
and with the cm109.c driver, which according to the comment in the code is derived
from this one, is this the right approach?
In the second patch I add two additional keys which could be handled by userspace:
"RING" whose purpose according to the user manual is to cycle all available ringtones
"MUTE" whose purpose is to mute the USB microphone
which KEY_* values should be used for them?
I have two more questions:
DRIVER_VERSION should be updated?
are both patches suitable for stable?
Daniele Forsi (2):
USB: input: yealink.c: use KEY_NUMERIC_* for numeric keys, star and
pound
USB: input: yealink.c: add mapping for "RING" and "MUTE" keys
drivers/input/misc/yealink.c | 43 +++++++++++++++++++------------------------
1 file changed, 19 insertions(+), 24 deletions(-)
--
2.1.3
^ permalink raw reply
* [RFC PATCH 1/2] USB: input: yealink.c: use KEY_NUMERIC_* for numeric keys, star and pound
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov
Cc: usbb2k-api-dev, linux-input, linux-kernel, Daniele Forsi
In-Reply-To: <1419259269-23820-1-git-send-email-dforsi@gmail.com>
Fix the "pound" key that being mapped to Shift+3 was returning '£' instead
of '#' when using an Italian keyboard mapping and use the same values as
the cm109.c driver (which was based on this yealink.c driver) also for '0'
to '9' and for '*'.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
---
drivers/input/misc/yealink.c | 39 +++++++++++++++------------------------
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 79c964c..e9403da 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -212,27 +212,24 @@ static int map_p1k_to_key(int scancode)
case 0x03: return KEY_ENTER; /* pickup */
case 0x14: return KEY_BACKSPACE; /* C */
case 0x13: return KEY_ESC; /* hangup */
- case 0x00: return KEY_1; /* 1 */
- case 0x01: return KEY_2; /* 2 */
- case 0x02: return KEY_3; /* 3 */
- case 0x10: return KEY_4; /* 4 */
- case 0x11: return KEY_5; /* 5 */
- case 0x12: return KEY_6; /* 6 */
- case 0x20: return KEY_7; /* 7 */
- case 0x21: return KEY_8; /* 8 */
- case 0x22: return KEY_9; /* 9 */
- case 0x30: return KEY_KPASTERISK; /* * */
- case 0x31: return KEY_0; /* 0 */
- case 0x32: return KEY_LEFTSHIFT |
- KEY_3 << 8; /* # */
+ case 0x00: return KEY_NUMERIC_1; /* 1 */
+ case 0x01: return KEY_NUMERIC_2; /* 2 */
+ case 0x02: return KEY_NUMERIC_3; /* 3 */
+ case 0x10: return KEY_NUMERIC_4; /* 4 */
+ case 0x11: return KEY_NUMERIC_5; /* 5 */
+ case 0x12: return KEY_NUMERIC_6; /* 6 */
+ case 0x20: return KEY_NUMERIC_7; /* 7 */
+ case 0x21: return KEY_NUMERIC_8; /* 8 */
+ case 0x22: return KEY_NUMERIC_9; /* 9 */
+ case 0x30: return KEY_NUMERIC_STAR; /* * */
+ case 0x31: return KEY_NUMERIC_0; /* 0 */
+ case 0x32: return KEY_NUMERIC_POUND; /* # */
}
return -EINVAL;
}
/* Completes a request by converting the data into events for the
* input subsystem.
- *
- * The key parameter can be cascaded: key2 << 8 | key1
*/
static void report_key(struct yealink_dev *yld, int key)
{
@@ -240,17 +237,13 @@ static void report_key(struct yealink_dev *yld, int key)
if (yld->key_code >= 0) {
/* old key up */
- input_report_key(idev, yld->key_code & 0xff, 0);
- if (yld->key_code >> 8)
- input_report_key(idev, yld->key_code >> 8, 0);
+ input_report_key(idev, yld->key_code, 0);
}
yld->key_code = key;
if (key >= 0) {
/* new valid key */
- input_report_key(idev, key & 0xff, 1);
- if (key >> 8)
- input_report_key(idev, key >> 8, 1);
+ input_report_key(idev, key, 1);
}
input_sync(idev);
}
@@ -966,9 +959,7 @@ static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)
for (i = 0; i < 256; i++) {
int k = map_p1k_to_key(i);
if (k >= 0) {
- set_bit(k & 0xff, input_dev->keybit);
- if (k >> 8)
- set_bit(k >> 8, input_dev->keybit);
+ set_bit(k, input_dev->keybit);
}
}
--
2.1.3
^ permalink raw reply related
* [RFC PATCH 2/2] USB: input: yealink.c: add mapping for "RING" and "MUTE" keys
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov
Cc: usbb2k-api-dev, linux-input, linux-kernel, Daniele Forsi
In-Reply-To: <1419259269-23820-1-git-send-email-dforsi@gmail.com>
According to the user manual of the "VOIP-3 SKY" USB phone, the RING
key is used to select different ring tones and the MUTE key is used
to mute the microphone.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
---
drivers/input/misc/yealink.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index e9403da..0b86c49 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -189,7 +189,9 @@ static int setChar(struct yealink_dev *yld, int el, int chr)
* USB-P1K button layout:
*
* up
+ * ring
* IN OUT
+ * mute
* down
*
* pickup C hangup
@@ -207,7 +209,9 @@ static int map_p1k_to_key(int scancode)
switch(scancode) { /* phone key: */
case 0x23: return KEY_LEFT; /* IN */
case 0x33: return KEY_UP; /* up */
+ case 0x44: return KEY_SOUND; /* ring */
case 0x04: return KEY_RIGHT; /* OUT */
+ case 0x41: return KEY_MICMUTE; /* mute */
case 0x24: return KEY_DOWN; /* down */
case 0x03: return KEY_ENTER; /* pickup */
case 0x14: return KEY_BACKSPACE; /* C */
--
2.1.3
^ permalink raw reply related
* [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-22 17:06 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, dtor; +Cc: anshul.g@samsung.com
Dear Mr. Dmitry and Linux Community,
I am Anshul Garg working on Linux Kernel from last 2 years .
I have one query regarding event filter mechanism in input subsystem.
Can you please help in answering my query as below:
==============================
=======================
In function input_pass_values in input.c file , input core sends all
events to each handler associated with
the input device ,
rcu_read_lock();
handle = rcu_dereference(dev->grab);
if (handle) {
count = input_to_handler(handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open)
count = input_to_handler(handle, vals, count);
}
after this in input_to_handler function events are filtered and sent
to the handler.
for (v = vals; v != vals + count; v++) {
if (handler->filter &&
handler->filter(handle, v->type, v->code, v->value))
continue;
if (end != v)
*end = *v;
end++;
}
But as per previous event filter mechanism all the events should be
parsed from all
handlers after that remaining events should be sent to handlers list.
And in comments also its mentioned as
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles.*/
So current approach to filter events seems to be incorrect.
Please help to clarify my query.
I have prepared one patch with new event filter mechanism which will
first filter all events from attached handlers then pass the remaining
events after being filtered
through all handlers unlike current implementation.
Once My query is resolved , I will send the patch.
Thanks
Anshul Garg
+91-9899777351
^ permalink raw reply
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Dmitry Torokhov @ 2014-12-22 17:26 UTC (permalink / raw)
To: Anshul Garg; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <CA+HOOsgL_fY=Wc+ciDAuk485d=uTn=YTgVGVDJ5Qk3UsqQ8zVA@mail.gmail.com>
Hi Anshul,
On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
> In function input_pass_values in input.c file , input core sends all
> events to each handler associated with the input device ,
>
> rcu_read_lock();
>
> handle = rcu_dereference(dev->grab);
> if (handle) {
> count = input_to_handler(handle, vals, count);
> } else {
> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
> if (handle->open)
> count = input_to_handler(handle, vals, count);
> }
>
> after this in input_to_handler function events are filtered and sent
> to the handler.
>
> for (v = vals; v != vals + count; v++) {
> if (handler->filter &&
> handler->filter(handle, v->type, v->code, v->value))
> continue;
> if (end != v)
> *end = *v;
> end++;
> }
>
>
>
> But as per previous event filter mechanism all the events should be
> parsed from all
> handlers after that remaining events should be sent to handlers list.
>
> And in comments also its mentioned as
>
> /*
> * Pass event first through all filters and then, if event has not been
> * filtered out, through all open handles.*/
>
> So current approach to filter events seems to be incorrect.
>
> Please help to clarify my query.
When you "grab" input device your handler gets exclusive access to all
events coming form it. Neither filer handlers nor regular input handlers
receive events from this device until you release it.
So I believe it works as intended.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-23 1:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <20141222172622.GA18556@dtor-ws>
Dear Mr Dmitry ,
Thanks for the reply.
I understand that if some handler grabs the input device then all
events will sent
to that handler only.
My Concern is If No one has grabbed the input device then all events
should go to
all handlers after application of all filter handlers.
For example : If 5 handlers registered for the input device.
Now among these 5 handlers 2 are filter handlers and remaining 3 are regular
input handlers.
In this case as per current implementation we pass the events array to
each handler.
Handler does its filtering then sent to handler.
What i am proposing is first we have to pass input_value list to all
filter handlers
After filteration of events, we can send the remaining events (Some
events might be removed
after filter) to all handlers.
In case device is grabbed we will just send the events to handler
which grabbed to device.
I hope to hear from you soon.
Thanks
On Mon, Dec 22, 2014 at 10:56 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Anshul,
>
> On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
>> In function input_pass_values in input.c file , input core sends all
>> events to each handler associated with the input device ,
>>
>> rcu_read_lock();
>>
>> handle = rcu_dereference(dev->grab);
>> if (handle) {
>> count = input_to_handler(handle, vals, count);
>> } else {
>> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
>> if (handle->open)
>> count = input_to_handler(handle, vals, count);
>> }
>>
>> after this in input_to_handler function events are filtered and sent
>> to the handler.
>>
>> for (v = vals; v != vals + count; v++) {
>> if (handler->filter &&
>> handler->filter(handle, v->type, v->code, v->value))
>> continue;
>> if (end != v)
>> *end = *v;
>> end++;
>> }
>>
>>
>>
>> But as per previous event filter mechanism all the events should be
>> parsed from all
>> handlers after that remaining events should be sent to handlers list.
>>
>> And in comments also its mentioned as
>>
>> /*
>> * Pass event first through all filters and then, if event has not been
>> * filtered out, through all open handles.*/
>>
>> So current approach to filter events seems to be incorrect.
>>
>> Please help to clarify my query.
>
> When you "grab" input device your handler gets exclusive access to all
> events coming form it. Neither filer handlers nor regular input handlers
> receive events from this device until you release it.
>
> So I believe it works as intended.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH v8 0/6] mfd: AXP20x: Add support for AXP202 and AXP209
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Carlo Caione
Hi everyone,
This is v8 of the AXP20x PMIC patches. These are the remaining patches
of the original series: PEK (power button) input driver, binding docs,
and defconfig updates.
Mark raised some questions during v7 about the first patch, specifically
about the "x-powers,dcdc-workmode" property. I've expanded the regulator
parts of the DT bindings doc. Mark, if you could take a look and give us
your blessing?
Dmitry, you were OK with the input bits going through the MFD tree, is
that still the case?
If there are no more problems, maybe Lee could take patches 1~4, and
Maxime can take the defconfig patches through his tree.
Thanks
ChenYu
Changes since v7:
- DT bindings
* Clarified the AXP's interrupt source
* Added explaination for "x-powers,dcdc-workmode" property
* Made regulator supply properties optional. They can be omitted
when the input is unregulated, as is the case when they are
connected to the IPSOUT output on the PMIC.
* Used real world example (Cubieboard2) for regulator nodes
- Fixed paths for PEK sysfs entries.
- PEK driver
* Made axp20x_pek_remove() in PEK driver static.
* Removed driver owner field.
* Wrapped some lines over 80 characters.
Original cover letter from v7:
During the merging of v6 several patches were left out. This v7 comprises
all the patches that are still pending.
//--
AXP209 and AXP202 are the PMUs (Power Management Unit) used by A10, A13
and A20 SoCs and developed by X-Powers, a sister company of Allwinner.
AXP20x comprises an adaptive USB-Compatible PWM charger, 2 BUCK DC-DC
converters, 5 LDOs, multiple 12-bit ADCs of voltage, current and temperature
as well as 4 configurable GPIOs.
This set of patches introduces the core driver and support for two different
subsystems:
- Regulators
- PEK (Power Enable Key)
Changes since v1:
- Added a new standalone patch for defconfig
- MFD core:
* Removed axp,system-power-controller property
- Bindings documentation:
* Corrected description for dcdc-workmode property
* Removed unused axp20x-pek compatible
- Input misc PEK driver:
* Fixed seconds in lower case
- Regulators subsystem:
* Fixed axp20x_set_suspend_voltage()
* Switched to using multi-bit control for regulators
* When "regulators" node is not found driver doesn't quit
* Driver is now using devm_regulator_register()
* Added module_platform_driver() instead of subsys_initcall()
- DT:
* Added new DTSI for AXP209
* Added support for cubietruck and olinuxino-micro
Changes since v2:
- Added a new patch for multi_v7_defconfig to enable MFD core
and subsystems
- DT:
* Dropped axp,system-power-controller property from DTS
* Moved compatible and interrupt-related properties from the
DTSI file to the DTS board files
- Regulators subsystem:
* Deleted useless struct axp20x_regulators
* Added a warning when out of specs values are used for the
dcdc frequency
- MFD core:
* Fixed coding style
* Removed IDs from device table for i2c
- Bindings documentation:
* Several corrections and fixes
Changes since v3:
- Removed x-powers-axp209.dtsi file
- Rewritten bindings document
- MFD core:
* Fixed casting
* Better comments / documentation
- Input misc PEK driver:
* Timings are now expressed in ms and the sysfs appies the
closest possible value
* No more useless pretty-printing
* Removed devm_request_threaded_irq in favour of
devm_request_any_context_irq
* Moved from input attributes to platform device attributes
- Regulators subsystem:
* Removed suspend mode (axp20x_set_suspend_voltage)
* Added regulators input supply
- DT:
* DTs doesn't include anymore the dtsi
* Added input supplies for regulators
Changes since v4:
- Removed regulator patches already applied / acked by Mark Brown
- Input misc PEK driver:
* Don't print anymore the "us" unit
* Added cleanup for attributes when unbindind the device
* Fixed error code returned when device_create_file() fails
- DT:
* Enable all the regulators on at boot-time
* Removed min and max microvolts for all the regulators but DCDC2
* Moved the axp_ipsout regulator outside the MFD node
- MFD core:
* The supply regulators are now specified in the MFD driver using
regulator_bulk_register_supply_alias() and the .parent_supplies
in the MFD cell
Changes since v5:
- Added ACKs
- Fixed compilation warning (reported by Hans De Goede)
- Vendor-prefixes are now sorted
- Removed DT patch
Carlo Caione (6):
mfd: AXP20x: Add bindings documentation
dt-bindings: add vendor-prefix for X-Powers
input: misc: Add driver for AXP20x Power Enable Key
input: misc: Add ABI docs for AXP20x PEK
ARM: sunxi: Add AXP20x support in defconfig
ARM: sunxi: Add AXP20x support multi_v7_defconfig
.../ABI/testing/sysfs-driver-input-axp-pek | 11 +
Documentation/devicetree/bindings/mfd/axp20x.txt | 97 +++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/configs/multi_v7_defconfig | 3 +
arch/arm/configs/sunxi_defconfig | 3 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 282 +++++++++++++++++++++
8 files changed, 409 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-input-axp-pek
create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
create mode 100644 drivers/input/misc/axp20x-pek.c
--
2.1.4
^ permalink raw reply
* [PATCH v8 1/6] mfd: AXP20x: Add bindings documentation
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Bindings documentation for the AXP20x driver. In this file also
sub-nodes are documented.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: clarify interrupt source for the axp PMIC]
[wens-jdAy2FN1RRM@public.gmane.org: explain dcdc-workmode in detail and trim lines to 80 chars]
[wens-jdAy2FN1RRM@public.gmane.org: make regulator supplies optional if using unregulated input]
[wens-jdAy2FN1RRM@public.gmane.org: use cubieboard2 regulator nodes as example]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 97 ++++++++++++++++++++++++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
new file mode 100644
index 000000000000..b775d8ccbc7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -0,0 +1,97 @@
+AXP202/AXP209 device tree bindings
+
+The axp20x family current members :
+axp202 (X-Powers)
+axp209 (X-Powers)
+
+Required properties:
+- compatible: "x-powers,axp202" or "x-powers,axp209"
+- reg: The I2C slave address for the AXP chip
+- interrupt-parent: The parent interrupt controller
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
+- interrupt-controller: axp20x has its own internal IRQs
+- #interrupt-cells: Should be set to 1
+- regulators: A node that houses a sub-node for each regulator. The regulators
+ are bound using their name as listed here: dcdc2, dcdc3, ldo1,
+ ldo2, ldo3, ldo4, ldo5. The bindings details of individual
+ regulator device can be found in:
+ Documentation/devicetree/bindings/regulator/regulator.txt with
+ the exception of x-powers,dcdc-freq. Regulators not used should
+ still be listed for completeness and that the regulator subsystem
+ properly registers them.
+
+- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
+ (range: 750-1875). Default: 1.5MHz
+
+Optional properties:
+- regulator supplies - may be omitted if inputs are unregulated, such as using
+ the IPSOUT output from the PMIC
+ - acin-supply: The input supply for LDO1
+ - vin2-supply: The input supply for DCDC2
+ - vin3-supply: The input supply for DCDC3
+ - ldo24in-supply: The input supply for LDO2, LDO4
+ - ldo3in-supply: The input supply for LDO3
+ - ldo5in-supply: The input supply for LDO5
+
+Optional properties for DCDC regulators:
+- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
+ Default: AUTO mode
+ The DCDC regulators work in a mixed PWM/PFM mode,
+ using PFM under light loads and switching to PWM
+ for heavier loads. Forcing PWM mode trades efficiency
+ under light loads for lower output noise. This
+ probably makes sense for HiFi audio related
+ applications that aren't battery constrained.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ x-powers,dcdc-freq = <1500>;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ vdd_int_dll: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+ };
+
+ vdd_rtc: ldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-rtc";
+ };
+
+ avcc: ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avcc";
+ };
+
+ ldo3 {
+ /* unused */
+ };
+
+ csi1_io_2v8: ldo4 {
+ /* output on extension headers */
+ regulator-name = "csi1-io-2v8";
+ };
+ };
+};
+
--
2.1.4
^ permalink raw reply related
* [PATCH v8 2/6] dt-bindings: add vendor-prefix for X-Powers
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b1df0ad1306c..1794fce3de80 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -172,6 +172,7 @@ voipac Voipac Technologies s.r.o.
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
+x-powers X-Powers
xes Extreme Engineering Solutions (X-ES)
xillybus Xillybus Ltd.
xlnx Xilinx
--
2.1.4
^ permalink raw reply related
* [PATCH v8 3/6] input: misc: Add driver for AXP20x Power Enable Key
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
This patch add support for the Power Enable Key found on MFD AXP202 and
AXP209. Besides the basic support for the button, the driver adds two
entries in sysfs to configure the time delay for power on/off.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: make axp20x_pek_remove() static; remove driver owner field]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 282 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 294 insertions(+)
create mode 100644 drivers/input/misc/axp20x-pek.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab6163f..a49bcd351e13 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -404,6 +404,17 @@ config INPUT_RETU_PWRBUTTON
To compile this driver as a module, choose M here. The module will
be called retu-pwrbutton.
+config INPUT_AXP20X_PEK
+ tristate "X-Powers AXP20X power button driver"
+ depends on MFD_AXP20X
+ help
+ Say Y here if you want to enable power key reporting via the
+ AXP20X PMIC.
+
+ To compile this driver as a module, choose M here. The module will
+ be called axp20x-pek.
+
+
config INPUT_TWL4030_PWRBUTTON
tristate "TWL4030 Power button Driver"
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c760361f80..04ea87fd600d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
+obj-$(CONFIG_INPUT_AXP20X_PEK) += axp20x-pek.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
new file mode 100644
index 000000000000..8dbd097ac939
--- /dev/null
+++ b/drivers/input/misc/axp20x-pek.c
@@ -0,0 +1,282 @@
+/*
+ * axp20x power button driver.
+ *
+ * Copyright (C) 2013 Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/errno.h>
+#include <linux/irq.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define AXP20X_PEK_STARTUP_MASK (0xc0)
+#define AXP20X_PEK_SHUTDOWN_MASK (0x03)
+
+struct axp20x_pek {
+ struct axp20x_dev *axp20x;
+ struct input_dev *input;
+ int irq_dbr;
+ int irq_dbf;
+};
+
+struct axp20x_time {
+ unsigned int time;
+ unsigned int idx;
+};
+
+static const struct axp20x_time startup_time[] = {
+ { .time = 128, .idx = 0 },
+ { .time = 1000, .idx = 2 },
+ { .time = 3000, .idx = 1 },
+ { .time = 2000, .idx = 3 },
+};
+
+static const struct axp20x_time shutdown_time[] = {
+ { .time = 4000, .idx = 0 },
+ { .time = 6000, .idx = 1 },
+ { .time = 8000, .idx = 2 },
+ { .time = 10000, .idx = 3 },
+};
+
+struct axp20x_pek_ext_attr {
+ const struct axp20x_time *p_time;
+ unsigned int mask;
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_startup_ext_attr = {
+ .p_time = startup_time,
+ .mask = AXP20X_PEK_STARTUP_MASK,
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_shutdown_ext_attr = {
+ .p_time = shutdown_time,
+ .mask = AXP20X_PEK_SHUTDOWN_MASK,
+};
+
+static struct axp20x_pek_ext_attr *get_axp_ext_attr(struct device_attribute *attr)
+{
+ return container_of(attr, struct dev_ext_attribute, attr)->var;
+}
+
+static ssize_t axp20x_show_ext_attr(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ unsigned int val;
+ int ret, i;
+
+ ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
+ if (ret != 0)
+ return ret;
+
+ val &= axp20x_ea->mask;
+ val >>= ffs(axp20x_ea->mask) - 1;
+
+ for (i = 0; i < 4; i++)
+ if (val == axp20x_ea->p_time[i].idx)
+ val = axp20x_ea->p_time[i].time;
+
+ return sprintf(buf, "%u\n", val);
+}
+
+static ssize_t axp20x_store_ext_attr(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ char val_str[20];
+ size_t len;
+ int ret, i;
+ unsigned int val, idx = 0;
+ unsigned int best_err = UINT_MAX;
+
+ val_str[sizeof(val_str) - 1] = '\0';
+ strncpy(val_str, buf, sizeof(val_str) - 1);
+ len = strlen(val_str);
+
+ if (len && val_str[len - 1] == '\n')
+ val_str[len - 1] = '\0';
+
+ ret = kstrtouint(val_str, 10, &val);
+ if (ret)
+ return ret;
+
+ for (i = 3; i >= 0; i--) {
+ unsigned int err;
+
+ err = abs(axp20x_ea->p_time[i].time - val);
+ if (err < best_err) {
+ best_err = err;
+ idx = axp20x_ea->p_time[i].idx;
+ }
+
+ if (!err)
+ break;
+ }
+
+ idx <<= ffs(axp20x_ea->mask) - 1;
+ ret = regmap_update_bits(axp20x_pek->axp20x->regmap,
+ AXP20X_PEK_KEY,
+ axp20x_ea->mask, idx);
+ if (ret != 0)
+ return -EINVAL;
+ return count;
+}
+
+static struct dev_ext_attribute axp20x_dev_attr_startup = {
+ .attr = __ATTR(startup, 0644, axp20x_show_ext_attr, axp20x_store_ext_attr),
+ .var = &axp20x_pek_startup_ext_attr
+};
+
+static struct dev_ext_attribute axp20x_dev_attr_shutdown = {
+ .attr = __ATTR(shutdown, 0644, axp20x_show_ext_attr, axp20x_store_ext_attr),
+ .var = &axp20x_pek_shutdown_ext_attr
+};
+
+static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
+{
+ struct input_dev *idev = pwr;
+ struct axp20x_pek *axp20x_pek = input_get_drvdata(idev);
+
+ if (irq == axp20x_pek->irq_dbr)
+ input_report_key(idev, KEY_POWER, true);
+ else if (irq == axp20x_pek->irq_dbf)
+ input_report_key(idev, KEY_POWER, false);
+
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_pek_probe(struct platform_device *pdev)
+{
+ struct axp20x_pek *axp20x_pek;
+ struct axp20x_dev *axp20x;
+ struct input_dev *idev;
+ int error;
+
+ axp20x_pek = devm_kzalloc(&pdev->dev, sizeof(struct axp20x_pek),
+ GFP_KERNEL);
+ if (!axp20x_pek)
+ return -ENOMEM;
+
+ axp20x_pek->axp20x = dev_get_drvdata(pdev->dev.parent);
+ axp20x = axp20x_pek->axp20x;
+
+ axp20x_pek->irq_dbr = platform_get_irq_byname(pdev, "PEK_DBR");
+ if (axp20x_pek->irq_dbr < 0) {
+ dev_err(&pdev->dev, "No IRQ for PEK_DBR, error=%d\n",
+ axp20x_pek->irq_dbr);
+ return axp20x_pek->irq_dbr;
+ }
+ axp20x_pek->irq_dbr = regmap_irq_get_virq(axp20x->regmap_irqc,
+ axp20x_pek->irq_dbr);
+
+ axp20x_pek->irq_dbf = platform_get_irq_byname(pdev, "PEK_DBF");
+ if (axp20x_pek->irq_dbf < 0) {
+ dev_err(&pdev->dev, "No IRQ for PEK_DBF, error=%d\n",
+ axp20x_pek->irq_dbf);
+ return axp20x_pek->irq_dbf;
+ }
+ axp20x_pek->irq_dbf = regmap_irq_get_virq(axp20x->regmap_irqc,
+ axp20x_pek->irq_dbf);
+
+ axp20x_pek->input = devm_input_allocate_device(&pdev->dev);
+ if (!axp20x_pek->input)
+ return -ENOMEM;
+
+ idev = axp20x_pek->input;
+
+ idev->name = "axp20x-pek";
+ idev->phys = "m1kbd/input2";
+ idev->dev.parent = &pdev->dev;
+
+ input_set_capability(idev, EV_KEY, KEY_POWER);
+
+ input_set_drvdata(idev, axp20x_pek);
+
+ error = devm_request_any_context_irq(&pdev->dev, axp20x_pek->irq_dbr,
+ axp20x_pek_irq, 0,
+ "axp20x-pek-dbr", idev);
+ if (error < 0) {
+ dev_err(axp20x->dev, "Failed to request dbr IRQ#%d: %d\n",
+ axp20x_pek->irq_dbr, error);
+
+ return error;
+ }
+
+ error = devm_request_any_context_irq(&pdev->dev, axp20x_pek->irq_dbf,
+ axp20x_pek_irq, 0,
+ "axp20x-pek-dbf", idev);
+ if (error < 0) {
+ dev_err(axp20x->dev, "Failed to request dbf IRQ#%d: %d\n",
+ axp20x_pek->irq_dbf, error);
+ return error;
+ }
+
+ error = device_create_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+ if (error)
+ return error;
+
+ error = device_create_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+ if (error)
+ goto clear_startup_attr;
+
+ error = input_register_device(idev);
+ if (error) {
+ dev_err(axp20x->dev, "Can't register input device: %d\n",
+ error);
+ goto clear_attr;
+ }
+
+ platform_set_drvdata(pdev, axp20x_pek);
+
+ return 0;
+
+clear_attr:
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+
+clear_startup_attr:
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+
+ return error;
+}
+
+static int axp20x_pek_remove(struct platform_device *pdev)
+{
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+
+ return 0;
+}
+
+static struct platform_driver axp20x_pek_driver = {
+ .probe = axp20x_pek_probe,
+ .remove = axp20x_pek_remove,
+ .driver = {
+ .name = "axp20x-pek",
+ },
+};
+module_platform_driver(axp20x_pek_driver);
+
+MODULE_DESCRIPTION("axp20x Power Button");
+MODULE_AUTHOR("Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* [PATCH v8 4/6] input: misc: Add ABI docs for AXP20x PEK
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Add ABI entries for the PEK found on PMU X-Powers AXP202 and AXP209.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: Fixed path for sysfs entries]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/ABI/testing/sysfs-driver-input-axp-pek | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-input-axp-pek
diff --git a/Documentation/ABI/testing/sysfs-driver-input-axp-pek b/Documentation/ABI/testing/sysfs-driver-input-axp-pek
new file mode 100644
index 000000000000..a5e671b9fa79
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-input-axp-pek
@@ -0,0 +1,11 @@
+What: /sys/class/input/input(x)/device/startup
+Date: March 2014
+Contact: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+Description: Startup time in us. Board is powered on if the button is pressed
+ for more than <startup_time>
+
+What: /sys/class/input/input(x)/device/shutdown
+Date: March 2014
+Contact: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+Description: Shutdown time in us. Board is powered off if the button is pressed
+ for more than <shutdown_time>
--
2.1.4
^ permalink raw reply related
* [PATCH v8 5/6] ARM: sunxi: Add AXP20x support in defconfig
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/configs/sunxi_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 7a342d2780a8..0a781e3c6de3 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -54,6 +54,8 @@ CONFIG_STMMAC_ETH=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=8
@@ -77,6 +79,7 @@ CONFIG_SUNXI_WATCHDOG=y
CONFIG_MFD_AXP20X=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_GPIO=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
2.1.4
^ permalink raw reply related
* [PATCH v8 6/6] ARM: sunxi: Add AXP20x support multi_v7_defconfig
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/configs/multi_v7_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2328fe752e9c..bef90c4ca984 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -191,6 +191,7 @@ CONFIG_TOUCHSCREEN_ATMEL_MXT=y
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MPU3050=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
@@ -278,6 +279,7 @@ CONFIG_SUNXI_WATCHDOG=y
CONFIG_MESON_WATCHDOG=y
CONFIG_MFD_AS3722=y
CONFIG_MFD_BCM590XX=y
+CONFIG_MFD_AXP20X=y
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_SPI=y
CONFIG_MFD_MAX77686=y
@@ -290,6 +292,7 @@ CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_AS3722=y
+CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_BCM590XX=y
CONFIG_REGULATOR_GPIO=y
CONFIG_MFD_SYSCON=y
--
2.1.4
^ permalink raw reply related
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-23 14:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <20141222172622.GA18556@dtor-ws>
Dear Mr Dmitry ,
Thanks for the reply.
I understand that if some handler grabs the input device then all
events will sent to that handler only.
My Concern is If No handler has grabbed the input device then all events
should go to all handlers after application of all filter handlers on
input event
list ( As we have to check for each event whether that event can be filtered
or not).
For example : If 5 handlers registered for the input device and input device is
not grabbed.
Now among these 5 handlers 2 are filter handlers and remaining 3 are regular
input handlers.
So we have to filter the event list first after applying 2 filters
then send the remaining
events to all registered handler.
In this case as per current implementation we pass the events array to
each handler. Input Core does events filtering fr handler then send remaining
events to handler.
What i am proposing is first we have to pass input_value list to all
filter handlers
After filteration of events, we can send the remaining events (Some
events might be removed after applying filter) to all handlers.
In case device is grabbed we will just send the events to handler
which grabbed to device.
I hope to hear from you soon.
Thanks
On Mon, Dec 22, 2014 at 10:56 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Anshul,
>
> On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
>> In function input_pass_values in input.c file , input core sends all
>> events to each handler associated with the input device ,
>>
>> rcu_read_lock();
>>
>> handle = rcu_dereference(dev->grab);
>> if (handle) {
>> count = input_to_handler(handle, vals, count);
>> } else {
>> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
>> if (handle->open)
>> count = input_to_handler(handle, vals, count);
>> }
>>
>> after this in input_to_handler function events are filtered and sent
>> to the handler.
>>
>> for (v = vals; v != vals + count; v++) {
>> if (handler->filter &&
>> handler->filter(handle, v->type, v->code, v->value))
>> continue;
>> if (end != v)
>> *end = *v;
>> end++;
>> }
>>
>>
>>
>> But as per previous event filter mechanism all the events should be
>> parsed from all
>> handlers after that remaining events should be sent to handlers list.
>>
>> And in comments also its mentioned as
>>
>> /*
>> * Pass event first through all filters and then, if event has not been
>> * filtered out, through all open handles.*/
>>
>> So current approach to filter events seems to be incorrect.
>>
>> Please help to clarify my query.
>
> When you "grab" input device your handler gets exclusive access to all
> events coming form it. Neither filer handlers nor regular input handlers
> receive events from this device until you release it.
>
> So I believe it works as intended.
>
> Thanks.
>
> --
> Dmitry
^ 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