* Re: [PATCH v3] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Barry Song @ 2014-02-18 6:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Xianglong Du, linux-input@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Rongjun Ying, Barry Song,
DL-SHA-WorkGroupLinux
In-Reply-To: <20140217191658.GA19223@core.coreip.homeip.net>
2014-02-18 3:16 GMT+08:00 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Fri, Feb 14, 2014 at 09:41:06PM +0800, Barry Song wrote:
>> >> Input: sirfsoc-onkey - implement open and close methods
>> >>
>> >> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> >>
>> >> We can control whetehr device generates interrupts or not so let's
>> >> implement open and close methods of input device so that we do not do any
>> >> processing until there are users.
>> >>
>> >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>
>> Tested-by: Xianglong Du <Xianglong.Du@csr.com>
>>
>> Dmitry, will you push this one to your tree so that i can rebase others?
>
> I rebased and pushed everything out, please take a look to make sure it
> all looks good.
thanks, we have done a update to CSR local tree.
>
> Thanks.
>
> --
> Dmitry
-barry
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Daniel J Blueman @ 2014-02-18 3:36 UTC (permalink / raw)
To: Peter Stuge; +Cc: linux-usb, linux-input, Dmitry Torokhov, Clinton Sprain
In-Reply-To: <20140218022105.14422.qmail@stuge.se>
On 18 February 2014 10:21, Peter Stuge <peter@stuge.se> wrote:
> Clinton Sprain wrote:
>> I noticed your examples are both fn combos. I'm seeing something like
>> this and it seems specifically related to the fn key. Reproducible on a
>> Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
>>
>> Press key
>> Press fn
>> Release key
>> Release fn
>>
>> The key will be 'stuck' until you press another key. It seems to only
>> apply to keys that are part of a fn combo
>
> Fn is handled by the embedded controller (H8 as per Intel reference
> design in case of Macbook or Thinkpad) which has its own closed
> firmware which is rarely perfectly bug-free.
The likelyhood that the root-cause was in an embedded controller was
holding me back from reporting it.
I believe the Mac keyboards use the generic HID driver in Windows, so
it may be that there isn't a device-specific workaround, but maybe a
generic workaround, though I can't reason the mechanism without more
input-stack-fu.
I guess one test hack to confirm our sanity would be to re-read the
key state every 100ms until a matching key-up is received, logging
when it detects a disparity between key state and no key-up
received...?
--
Daniel J Blueman
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Peter Stuge @ 2014-02-18 2:21 UTC (permalink / raw)
To: Clinton Sprain
Cc: Daniel J Blueman, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov
In-Reply-To: <5302C0B2.9010506-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Clinton Sprain wrote:
> I noticed your examples are both fn combos. I'm seeing something like
> this and it seems specifically related to the fn key. Reproducible on a
> Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
>
> Press key
> Press fn
> Release key
> Release fn
>
> The key will be 'stuck' until you press another key. It seems to only
> apply to keys that are part of a fn combo
Fn is handled by the embedded controller (H8 as per Intel reference
design in case of Macbook or Thinkpad) which has its own closed
firmware which is rarely perfectly bug-free.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Clinton Sprain @ 2014-02-18 2:08 UTC (permalink / raw)
To: Daniel J Blueman, linux-usb, linux-input; +Cc: Dmitry Torokhov
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>
I noticed your examples are both fn combos. I'm seeing something like
this and it seems specifically related to the fn key. Reproducible on a
Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
Press key
Press fn
Release key
Release fn
The key will be 'stuck' until you press another key. It seems to only
apply to keys that are part of a fn combo, so affected keys vary from
one model to another; it appears that if nothing is mapped to fn+key on
a given hardware, the key is not affected. For example, delete is
affected on the Macbook (which has fn+delete = backspace), but not on
the Yoga (which has a dedicated backspace key). Arrow keys are an
exception to this rule though.
Is this what you're seeing?
- Clinton
On 02/17/2014 07:23 AM, Daniel J Blueman wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
>
> This has occurred on Apple laptops, external USB keyboards and Dell
> laptops, so seems like a linux USB input issue, as I haven't seen
> occur on Windows or MacOS on the same hardware.
>
> It seems a good move for me to rebuild and run a kernel with some USB
> HID instrumentation to locate this issue over time. Without apriori
> knowledge of the linux USB input stack, what is a good initial
> approach?
>
> Thanks,
> Daniel
^ permalink raw reply
* [PATCH] HID: cp2112: convert to use hid_hw_raw_request()
From: Jiri Kosina @ 2014-02-17 23:43 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input, fengguang.wu
Commit cafebc0 ("HID: remove hid_get_raw_report in struct hid_device")
obsoletes the use of hdev->hid_get_raw_report(), as calling
hid_hw_raw_request() is functionally equivalent.
Convert cp2112 to use this notation.
Reported-by: fengguang.wu@intel.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index f326726..6d679f1 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -174,8 +174,9 @@ static int cp2112_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
u8 buf[5];
int ret;
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_CONFIG, buf,
- sizeof(buf), HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
+ sizeof(buf), HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO config: %d\n", ret);
return ret;
@@ -220,8 +221,8 @@ static int cp2112_gpio_get(struct gpio_chip *chip, unsigned offset)
u8 buf[2];
int ret;
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_GET, buf, sizeof(buf),
- HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_GET, buf, sizeof(buf),
+ HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO values: %d\n", ret);
return ret;
@@ -241,8 +242,9 @@ static int cp2112_gpio_direction_output(struct gpio_chip *chip,
cp2112_gpio_set(chip, offset, value);
- ret = hdev->hid_get_raw_report(hdev, CP2112_GPIO_CONFIG, buf,
- sizeof(buf), HID_FEATURE_REPORT);
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
+ sizeof(buf), HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
if (ret != sizeof(buf)) {
hid_err(hdev, "error requesting GPIO config: %d\n", ret);
return ret;
@@ -271,8 +273,8 @@ static int cp2112_hid_get(struct hid_device *hdev, unsigned char report_number,
if (!buf)
return -ENOMEM;
- ret = hdev->hid_get_raw_report(hdev, report_number, buf, count,
- report_type);
+ ret = hid_hw_raw_request(hdev, report_number, buf, count,
+ report_type, HID_REQ_GET_REPORT);
memcpy(data, buf, count);
kfree(buf);
return ret;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH 2/2] HID: cp2112: use proper specifier for size_t
From: Jiri Kosina @ 2014-02-17 22:48 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input
In-Reply-To: <alpine.LNX.2.00.1402172346500.1192@pobox.suse.cz>
%zd is a proper format string specifier for size_t
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 57cf045..f326726 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -361,7 +361,7 @@ static int cp2112_read(struct cp2112_device *dev, u8 *data, size_t size)
if (ret)
return ret;
- hid_dbg(hdev, "read %d of %d bytes requested\n",
+ hid_dbg(hdev, "read %d of %zd bytes requested\n",
dev->read_length, size);
if (size > dev->read_length)
@@ -552,7 +552,7 @@ static int cp2112_xfer(struct i2c_adapter *adap, u16 addr,
if (ret < 0)
goto power_normal;
if (ret != read_length) {
- hid_warn(hdev, "short read: %d < %d\n", ret, read_length);
+ hid_warn(hdev, "short read: %d < %zd\n", ret, read_length);
ret = -EIO;
goto power_normal;
}
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH 1/2] HID: cp2112: make sysfs attributes static
From: Jiri Kosina @ 2014-02-17 22:47 UTC (permalink / raw)
To: David Barksdale; +Cc: linux-input
No need to pollute namespace with dev_attr_*.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cp2112.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index ca0f356..57cf045 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -663,7 +663,7 @@ static ssize_t name##_show(struct device *kdev, \
return ret; \
return scnprintf(buf, PAGE_SIZE, format, ##__VA_ARGS__); \
} \
-DEVICE_ATTR_RW(name);
+static DEVICE_ATTR_RW(name);
CP2112_CONFIG_ATTR(vendor_id, ({
u16 vid;
@@ -784,7 +784,7 @@ static ssize_t pstr_show(struct device *kdev,
}
#define CP2112_PSTR_ATTR(name, _report) \
-struct cp2112_pstring_attribute dev_attr_##name = { \
+static struct cp2112_pstring_attribute dev_attr_##name = { \
.attr = __ATTR(name, (S_IWUSR | S_IRUGO), pstr_show, pstr_store), \
.report = _report, \
};
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH] HID: sony: Correct Sixaxis battery reporting
From: Jiri Kosina @ 2014-02-17 22:18 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input
In-Reply-To: <1392489342-5401-1-git-send-email-frank.praznik@oh.rr.com>
On Sat, 15 Feb 2014, Frank Praznik wrote:
> The battery_charging and cable_state flags were backwards on the Sixaxis.
> The low bit of report byte 30 is 0 when charging and 1 when not.
> Bit 5 of byte 31 is 0 when a USB cable is connected and 1 when not.
>
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Applied, thanks Frank.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] Input: imx_keypad -Remove obsolete commment
From: Fabio Estevam @ 2014-02-17 20:26 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit 81e8f2bc (Input: imx_keypad - add pm suspend and resume support)
the imx_keypad driver supports power management, so remove the obsolete comment.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/input/keyboard/imx_keypad.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
index cbf4f80..80091c2 100644
--- a/drivers/input/keyboard/imx_keypad.c
+++ b/drivers/input/keyboard/imx_keypad.c
@@ -6,7 +6,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
- * <<Power management needs to be implemented>>.
*/
#include <linux/clk.h>
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-02-17 20:21 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, David Herrmann, open list:HID CORE LAYER,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <37F7D8DE-5861-4452-B2F7-00D5E5F952B0-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Mon, 17 Feb 2014, Marcel Holtmann wrote:
> >> Gustavo, what is your take on this please? I can take it through hid.git
> >> in case you don't have anything else queued for -rc2.
> >
> > ... ping?
> >
> > In case this doesn't get reacted upon by the end of the week, I am
> > inclined to take it through hid.git.
>
> take it through hid.git please.
Now applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* RE: [PATCH] HID: hyperv: make sure input buffer is big enough
From: Jiri Kosina @ 2014-02-17 20:21 UTC (permalink / raw)
To: KY Srinivasan
Cc: David Herrmann, linux-input@vger.kernel.org, Dan Carpenter,
Joseph Salisbury, Haiyang Zhang, linux-kernel@vger.kernel.org
In-Reply-To: <5bae77400133466d9698c925bfe58df5@BY2PR03MB299.namprd03.prod.outlook.com>
On Thu, 19 Dec 2013, KY Srinivasan wrote:
> > We need at least HID_MAX_BUFFER_SIZE (4096) bytes as input buffer. HID
> > core depends on this as it requires every input report to be at least as
> > big as advertised.
> >
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Now applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Bruno Prémont @ 2014-02-17 20:11 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: linux-input, linux-usb, Linux Kernel, Dmitry Torokhov
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>
On Mon, 17 February 2014 Daniel J Blueman <daniel@quora.org> wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
>
> This has occurred on Apple laptops, external USB keyboards and Dell
> laptops, so seems like a linux USB input issue, as I haven't seen
> occur on Windows or MacOS on the same hardware.
>
> It seems a good move for me to rebuild and run a kernel with some USB
> HID instrumentation to locate this issue over time. Without apriori
> knowledge of the linux USB input stack, what is a good initial
> approach?
I've seen some similar behavior on servers connected to a KVM switch
(USB keyboard/mouse) where without apparent reason the ENTER key became
pressed and did continuously send repeat events.
Physically touching the KVM keyboard or unbinding&rebinding the HID
keyboard solved the issue (on a console that triggers a busy loop of
agettys on active vt).
I've been tempted to attribute it to the KVM switch doing something
when switching to another server via key-press (yes, some co-worker
as at the KVM terminal when the getty load started).
On the other hand, some other co-worker had "dead keyboard" issues
though only under X, things still worked at console level, for quite
some time now. Annoying but not regular enough to look further into it.
If you want to look at what happens for you, monitoring the USB activity
for your keyboard (in combination with output from event device) might
be the most useful way (it would also catch details on when the USB
side goes into power-saving, if at all).
Bruno
^ permalink raw reply
* Re: [PATCH 2/2] Input: imx_keypad - Omit error message devm_kzalloc() failure
From: Dmitry Torokhov @ 2014-02-17 19:34 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, Fabio Estevam
In-Reply-To: <1392433187-7756-2-git-send-email-festevam@gmail.com>
On Sat, Feb 15, 2014 at 12:59:47AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> There is no need to print an error message in the driver for devm_kzalloc()
> failure because OOM core code handles it properly.
I'd rather keep this in. We may change OOM messaging at later time
making it less verbose.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/input/keyboard/imx_keypad.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index de07035..40ad98d 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -450,10 +450,8 @@ static int imx_keypad_probe(struct platform_device *pdev)
>
> keypad = devm_kzalloc(&pdev->dev, sizeof(struct imx_keypad),
> GFP_KERNEL);
> - if (!keypad) {
> - dev_err(&pdev->dev, "not enough memory for driver data\n");
> + if (!keypad)
> return -ENOMEM;
> - }
>
> keypad->input_dev = input_dev;
> keypad->irq = irq;
> --
> 1.8.1.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: imx_keypad - Propagate the real error code on platform_get_irq() failure
From: Dmitry Torokhov @ 2014-02-17 19:33 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, Fabio Estevam
In-Reply-To: <1392433187-7756-1-git-send-email-festevam@gmail.com>
On Sat, Feb 15, 2014 at 12:59:46AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> No need to return a 'fake' return value on platform_get_irq() failure.
>
> Just return the error code itself instead.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thank you.
> ---
> drivers/input/keyboard/imx_keypad.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index cbf4f80..de07035 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -439,7 +439,7 @@ static int imx_keypad_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(&pdev->dev, "no irq defined in platform data\n");
> - return -EINVAL;
> + return irq;
> }
>
> input_dev = devm_input_allocate_device(&pdev->dev);
> --
> 1.8.1.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH V2] ONKEY: da9052: Use correct register bit for key status
From: Dmitry Torokhov @ 2014-02-17 19:29 UTC (permalink / raw)
To: Anthony Olech; +Cc: Paul Gortmaker, linux-input, linux-kernel, David Dajun Chen
In-Reply-To: <201402121518.s1CFIkDP009092@swsrvapps-02.lan>
On Wed, Feb 12, 2014 at 02:11:34PM +0000, Anthony Olech wrote:
> The wrong register bit of the DA9052/3 PMIC registers was
> used to determine the status on the ONKEY.
>
> Also a failure in reading the status register will no longer
> result in the work queue being rescheduled as that would result
> in a (potentially) endless retry.
>
> Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
> Acked-by: David Dajun Chen <david.chen@diasemi.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()
From: Dmitry Torokhov @ 2014-02-17 19:23 UTC (permalink / raw)
To: Christopher Heiny
Cc: Andrew Duggan, Vincent Huang, Vivian Ly, Daniel Rosenberg,
Linus Walleij, Benjamin Tissoires, Courtney Cavin, Linux Input,
Linux Kernel
In-Reply-To: <52FEA01B.7040604@synaptics.com>
On Fri, Feb 14, 2014 at 03:00:43PM -0800, Christopher Heiny wrote:
> On 02/13/2014 01:54 PM, Dmitry Torokhov wrote:
> >On Thu, Feb 13, 2014 at 11:23:44AM -0800, Christopher Heiny wrote:
> >>>On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:
> >>>> >Do not write configuration data in probe(), we have config() for that.
> >>>
> >>>Then we should call config() in rmi_function_probe() to ensure that
> >>>any platform data or device tree configuration settings get written
> >>>to the device.
> >
> >Well, yes, we may elect to update device configuration in probe, but
> >then we should not be doing that 2nd time in ->config(). We shoudl pick
> >either one or another.
>
> But as the code currently stands, config() is only called when a
> device reset is detected, not during initialization. So if there's
> platform specific configuration data that needs to be written to a
> function, it won't get written until after a device reset occurs,
> which might never happen. So either we need to write that data (or
> call config()) in each function's probe(), or in
> rmi_function_probe().
Ah, I missed the fact that we do not normally call ->config() unless
device was reset. BTW, if device was reset, shouldn't we tear down
everything and then reenumerate all functions?
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Dmitry Torokhov @ 2014-02-17 19:16 UTC (permalink / raw)
To: Barry Song
Cc: Xianglong Du, linux-input@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, DL-SHA-WorkGroupLinux,
Rongjun Ying, Barry Song
In-Reply-To: <CAGsJ_4zjtWV3Z1AJ2bqekXn54rm=k8d4iOi_zzainCEnNGefCw@mail.gmail.com>
On Fri, Feb 14, 2014 at 09:41:06PM +0800, Barry Song wrote:
> >> Input: sirfsoc-onkey - implement open and close methods
> >>
> >> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >>
> >> We can control whetehr device generates interrupts or not so let's
> >> implement open and close methods of input device so that we do not do any
> >> processing until there are users.
> >>
> >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Tested-by: Xianglong Du <Xianglong.Du@csr.com>
>
> Dmitry, will you push this one to your tree so that i can rebase others?
I rebased and pushed everything out, please take a look to make sure it
all looks good.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Marcel Holtmann @ 2014-02-17 16:32 UTC (permalink / raw)
To: Jiri Kosina
Cc: Gustavo F. Padovan, David Herrmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <alpine.LNX.2.00.1402171506450.1192@pobox.suse.cz>
Hi Jiri,
>>>>>>>> just got back to this, finally ... did you have time to work on this at
>>>>>>>> all, or should I just start from scratch?
>>>>>>>
>>>>>>> Sorry, no. Fosdem is this weekend and I needed to get my code ready
>>>>>>> for that. But I'll finally have time again next week.
>>>>>>
>>>>>> Okay, thanks. I then guess we should proceed with this bandaid (double
>>>>>> allocation) for 3.14
>>>>>
>>>>> It would be really nice if we could get the HIDP patch into 3.14-rc2
>>>>> and backported to stable. There have been quite a bunch of reports now
>>>>> and I dislike adding a GFP_ATOMIC allocation in HID core.
>>>>
>>>> I agree with David; Gustavo, what is your take on this, please?
>>>
>>> I leave this up to Gustavo to get this into wireless tree for 3.14-rc2.
>>>
>>> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>>
>> Thanks a lot.
>>
>> Gustavo, what is your take on this please? I can take it through hid.git
>> in case you don't have anything else queued for -rc2.
>
> ... ping?
>
> In case this doesn't get reacted upon by the end of the week, I am
> inclined to take it through hid.git.
take it through hid.git please.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v1] HID: hid-sensor-hub: Processing for duplicate physical ids
From: Jiri Kosina @ 2014-02-17 16:16 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: jic23, linux-input, Archana Patni
In-Reply-To: <1391198650-15468-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Fri, 31 Jan 2014, Srinivas Pandruvada wrote:
> In HID sensor hub, HID physical ids are used to represent different
> sensors. For example physical id of 0x73 in usage page = 0x20, represents
> an accelerometer. The HID sensor hub driver uses this physical ids to
> create platform devices using MFD. There is 1:1 correspondence between
> an phy id and a client driver.
> But in some cases these physical ids are reused. There is a phy id 0xe1,
> which specifies a custom sensor, which can exist multiple times to represent
> various custom sensors. In this case there can be multiple instances
> of client MFD drivers, processing specific custom sensor. In this
> case when client driver looks for report id or a field index, it
> should still get the report id specific to its own type. This is
> also true for reports, they should be directed towards correct instance.
> This change introduce a way to parse and tie physical devices to their
> correct instance.
> Summary of changes:
> - To get physical ids, use collections. If a collection of type=physical
> exist then use usage id as in the name of platform device name
> - As part of the platform data, we assign a hdsev instance, which has
> start and end of collection indexes. Using these indexes attributes
> can be tied to correct MFD client instances
> - When a report is received, call callback with correct hsdev instance.
> In this way using its private data stored as part of its registry, it
> can distinguish different sensors even when they have same physical and
> logical ids.
> This patch is co-authored with Archana Patni<archna.patni@intel.com>.
I have massaged the changelog a little bit, and applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: PROBLEM: Kernel-Panic when using Apple-Magic-Trackpad
From: Jiri Kosina @ 2014-02-17 16:10 UTC (permalink / raw)
To: Gerrit Addiks; +Cc: linux-input, David Herrmann, Gustavo F. Padovan
In-Reply-To: <52ED19F6.7020700@addiks.de>
On Sat, 1 Feb 2014, Gerrit Addiks wrote:
> Thank you for showing me that patch. After a couple days of testing it i can
> pretty clearly say that this patch fixes the kernel-panic for me. I hope the
> patch finds it's way into the public kernel repository as soon as possible.
>
> I have compiled two kernels from the latest version (git: master), one patched
> and one unpatched: While the patched version worked flawlessly for days, the
> unpatched version got multiple times into kernel-panic after just seconds.
Thanks for testing. I am now waiting for the BT guys to pick it up. My
plan is to push it for -rc4 myself if it doesn't go through bluetooth
tree.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] iio: hid-sensor-hub: Remove hard coded indexes
From: Jiri Kosina @ 2014-02-17 14:10 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Srinivas Pandruvada, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52F619C9.8060701-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Sat, 8 Feb 2014, Jonathan Cameron wrote:
> > > Remove the hard coded indexes, instead search for usage id and
> > > use the index to set the power and report state.
> > > This will fix issue, where the report descriptor doesn't contain
> > > the full list of possible selector for power and report state.
> > >
> > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Jonathan, I'd probably take this together with the patch for HID API
> > change. Could you please provide your Ack/Signoff, and I'll take it
> > through my tree, if you agree?
> Agreed. Help yourself ;)
Thanks! Now applied.
> Thanks and sorry for the slow response. Amazing the backlog that builds
> up if you take about 3 weeks out (more or less)
Yeah, it basically immediately destroys all the energy you gained during
the time off :)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-02-17 14:07 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo F. Padovan
Cc: David Herrmann, open list:HID CORE LAYER,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <alpine.LNX.2.00.1402051648470.8614-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
On Wed, 5 Feb 2014, Jiri Kosina wrote:
> > >>>>> just got back to this, finally ... did you have time to work on this at
> > >>>>> all, or should I just start from scratch?
> > >>>>
> > >>>> Sorry, no. Fosdem is this weekend and I needed to get my code ready
> > >>>> for that. But I'll finally have time again next week.
> > >>>
> > >>> Okay, thanks. I then guess we should proceed with this bandaid (double
> > >>> allocation) for 3.14
> > >>
> > >> It would be really nice if we could get the HIDP patch into 3.14-rc2
> > >> and backported to stable. There have been quite a bunch of reports now
> > >> and I dislike adding a GFP_ATOMIC allocation in HID core.
> > >
> > > I agree with David; Gustavo, what is your take on this, please?
> >
> > I leave this up to Gustavo to get this into wireless tree for 3.14-rc2.
> >
> > Acked-by: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
>
> Thanks a lot.
>
> Gustavo, what is your take on this please? I can take it through hid.git
> in case you don't have anything else queued for -rc2.
... ping?
In case this doesn't get reacted upon by the end of the week, I am
inclined to take it through hid.git.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: quirk for STM Sensor hub
From: Jiri Kosina @ 2014-02-17 14:05 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Archana Patni, linux-input, srinivas.pandruvada
In-Reply-To: <52FF48E7.9070400@kernel.org>
On Sat, 15 Feb 2014, Jonathan Cameron wrote:
> > We look for usage id for "power and report state", and modify
> > logical minimum value to 1.
> >
> > This is a follow-up patch to commit id 875e36f8.
> >
> > Signed-off-by: Archana Patni <archana.patni@linux.intel.com>
> > Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Hi Jiri,
>
> I'm fine with any of these going in through the hid tree without without
> my Ack given they are just marking which drivers need the quirk and
> which do not.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 00/14] HID: low-level transport cleanup, round 2
From: Jiri Kosina @ 2014-02-17 14:01 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, David Herrmann, linux-input, linux-kernel
In-Reply-To: <1392055139-19631-1-git-send-email-benjamin.tissoires@redhat.com>
On Mon, 10 Feb 2014, Benjamin Tissoires wrote:
> this is the second part of the low-level HID transport cleanup.
> The series goes on top of the previous one I sent last week.
Thanks!
I have applied all but patches 7,11,12 (and 13 as a natural followup). I
am waiting for v2 of 7 and 12, and I want to think a little bit more about
11.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* USB keyboard occasional key stuck
From: Daniel J Blueman @ 2014-02-17 13:23 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Linux Kernel
Cc: Dmitry Torokhov
Across 5+ years of kernels, I've been seeing occasional (1-2 times per
day) key-stuck issues where eg a fn+delete combo repeats delete until
I press delete again. I've seen this happen with fn+ctrl+left, leaving
left held and likewise with right.
This has occurred on Apple laptops, external USB keyboards and Dell
laptops, so seems like a linux USB input issue, as I haven't seen
occur on Windows or MacOS on the same hardware.
It seems a good move for me to rebuild and run a kernel with some USB
HID instrumentation to locate this issue over time. Without apriori
knowledge of the linux USB input stack, what is a good initial
approach?
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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