* Re: [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock
From: Henrique de Moraes Holschuh @ 2013-08-23 18:18 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-acpi, linux-input, linux-kernel, mjg, rjw, len.brown, dtor
In-Reply-To: <1377180132-4933-3-git-send-email-Jason@zx2c4.com>
On Thu, 22 Aug 2013, Jason A. Donenfeld wrote:
> Thinkpads with a micmute LED do not have a capslock LED. The micmute LED
> is currently not used by any piece of Linux kernel land or user land. It
> seems reasonable to hook it up to caps lock, at least by default, so
> users can have some degree of functionality.
NACK. This we won't do. It is a LED misuse, and it will get in the way
when we finally put that LED to its proper use.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH 2/3] thinkpad_acpi: Support micmute LED
From: Henrique de Moraes Holschuh @ 2013-08-23 18:16 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-acpi, linux-input, linux-kernel, mjg, rjw, len.brown, dtor
In-Reply-To: <1377180132-4933-2-git-send-email-Jason@zx2c4.com>
Hi Jason!
On Thu, 22 Aug 2013, Jason A. Donenfeld wrote:
> The micmute LED is currently unused. This patch allows it to be hooked
> up to various LED triggers.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> drivers/platform/x86/thinkpad_acpi.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 54d31c0..33b23cb 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -5050,8 +5050,10 @@ static const char * const tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
> "tpacpi::unknown_led2",
> "tpacpi::unknown_led3",
> "tpacpi::thinkvantage",
> + "tpacpi::unknown_led4",
> + "tpacpi::micmute"
> };
> -#define TPACPI_SAFE_LEDS 0x1081U
> +#define TPACPI_SAFE_LEDS 0x5081U
Micmute is not a "safe" LED by thinkpad-acpi's definition.
Besides, I want to see that LED hooked to alsa, any other use should be
protected by a module parameter (like fan-control is) or kernel config (like
unsafe LEDs are).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: kernel Oops: 0003 on usbhid_submit_report
From: Andreas Lillebø Holm @ 2013-08-23 12:51 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, Greg KH, linux-usb, linux-input
In-Reply-To: <alpine.LNX.2.00.1308231447440.11021@pobox.suse.cz>
>
> All three reported oopses happened on page boundary exactly, so this
> pretty much looks like my implement() fix is the one.
>
> Andreas, could you please apply
>
> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=27ce405039bfe6d3f4143415c638f56a3df77dca
>
> and report back whether it makes your problem go away?
I will build and test this patch and hopefully it will resolve my issues :)
--
Andreas Lillebø Holm
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel Oops: 0003 on usbhid_submit_report
From: Jiri Kosina @ 2013-08-23 12:49 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Andreas Lillebø Holm, Greg KH,
linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-input
In-Reply-To: <CAN+gG=FJSMyQNHcq=0cO1srVpRb_83YihUH0WuAPTcKAJHhv4g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 23 Aug 2013, Benjamin Tissoires wrote:
> IIRC, Jiri fixed some paging requests with the two following patches:
> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=27ce405039bfe6d3f4143415c638f56a3df77dca
> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bc197eedef1ae082ec662c64c3f4aa302821fb7a
>
> At least, these two patches are related to hid_output_report(). I
> think they are scheduled for 3.12, so I can not find them in Linus'
> tree.
>
> It would worth trying them :)
All three reported oopses happened on page boundary exactly, so this
pretty much looks like my implement() fix is the one.
Andreas, could you please apply
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=27ce405039bfe6d3f4143415c638f56a3df77dca
and report back whether it makes your problem go away?
Thanks,
--
Jiri Kosina
SUSE Labs
--
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: kernel Oops: 0003 on usbhid_submit_report
From: Benjamin Tissoires @ 2013-08-23 12:32 UTC (permalink / raw)
To: Andreas Lillebø Holm
Cc: Greg KH, Jiri Kosina, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input
In-Reply-To: <26E21BF00B944AB6B8F48B5E59B0442D-nr7O5T6ryCTQT0dZR+AlfA@public.gmane.org>
On Fri, Aug 23, 2013 at 12:52 PM, Andreas Lillebø Holm
<andreas-nr7O5T6ryCTQT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
> I just wanna followup this issue a bit more.
>
> We have now tested on several hardware platform, and it is only on one platform it fails. The platform it fails on is Atom Intel e6xx CPU with EG20T PCH platform controller. We do not observe it on the Intel i7 3517UE CPU with Intel 6/7 series system controller.
>
> We see this error around 4 times over 100 boots / 2 hours runtime.
>
> After the Oops our process is in uninterruptable sleep state (D state). The process is not killable when in this state. The process also uses around 70% CPU, maybe because it is waiting for the ioctl system call to return?
>
> We haven't found another way to recover from besides rebooting the system.
>
> How can we proceed to fix this issue?
IIRC, Jiri fixed some paging requests with the two following patches:
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=27ce405039bfe6d3f4143415c638f56a3df77dca
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bc197eedef1ae082ec662c64c3f4aa302821fb7a
At least, these two patches are related to hid_output_report(). I
think they are scheduled for 3.12, so I can not find them in Linus'
tree.
It would worth trying them :)
Cheers,
Benjamin
>
>
> On Thursday, August 15, 2013 at 8:37 AM, Greg KH wrote:
>
>> > > > When communicating with AT90USB1287, at random intervals (1/25 boots)
>> > > > the linux hid_output_field Oopses and kills the communicating thread.
>> > > > The AT90USB1287 microcontroller uses LUFA library for usb/hid
>> > > > communication. It is trigged by a ioctl call from userspace and fails
>> > > > in a kernel paging request. The system is after the oops in a state
>> > > > where no hid commands is sent anymore and only a boot can fix the
>> > > > system.
>> > > >
>> > > > Keywords: usbhid hid
>> > > >
>> > > > Kernel version: Linux version 3.8.13-03081301-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201305311535 SMP Fri May 31 19:44:30 UTC 2013
>> > > >
>> > > > Oopses:
>> > > > http://paste.debian.net/24305
>> > > > http://paste.debian.net/24306
>> > > > http://paste.debian.net/24307
>> > > >
>> > > > Code:
>> > > > The error is triggered by:
>> > > > ioctl(fd,HIDIOCSUSAGES, &ref_multi_u);
>> > > > ioctl(fd,HIDIOCSREPORT, &rep_info_u);
>> > > >
>> > > > Notes:
>> > > > It is very hard to reproduce so seems like race condition…
>> > > >
>> > > > Any tips to resolve/workaround this issue is appreciated and please
>> > > > let me know if my information is incomplete (This is my first kernel
>> > > > bug report)
>> > >
>> > >
>> > > Any chance you can try a supported kernel, like 3.10.6 or 3.11-rc5 to
>> > > see if that also causes problems? We can't do anything with
>> > > distro-specific kernel releases like your 3.8.13 release from Ubuntu,
>> > > sorry.
>> >
>> >
>> > I've now tried with kernel 3.10.6 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.6-saucy/) and I can trigger the same issue on this kernel.
>> >
>> > Here is a paste from last Oops on this kernel:
>> > http://paste.debian.net/24993/
>> >
>> > I am also using usbmon to monitor the usb bus traffic, but cannot see anything that should cause the driver to Oops.
>> >
>> > Is there any way to find out what can trigger this issue?
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: kernel Oops: 0003 on usbhid_submit_report
From: Andreas Lillebø Holm @ 2013-08-23 10:52 UTC (permalink / raw)
To: Greg KH
Cc: Jiri Kosina, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130815063736.GF25754-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Hi,
I just wanna followup this issue a bit more.
We have now tested on several hardware platform, and it is only on one platform it fails. The platform it fails on is Atom Intel e6xx CPU with EG20T PCH platform controller. We do not observe it on the Intel i7 3517UE CPU with Intel 6/7 series system controller.
We see this error around 4 times over 100 boots / 2 hours runtime.
After the Oops our process is in uninterruptable sleep state (D state). The process is not killable when in this state. The process also uses around 70% CPU, maybe because it is waiting for the ioctl system call to return?
We haven't found another way to recover from besides rebooting the system.
How can we proceed to fix this issue?
Andreas
On Thursday, August 15, 2013 at 8:37 AM, Greg KH wrote:
> > > > When communicating with AT90USB1287, at random intervals (1/25 boots)
> > > > the linux hid_output_field Oopses and kills the communicating thread.
> > > > The AT90USB1287 microcontroller uses LUFA library for usb/hid
> > > > communication. It is trigged by a ioctl call from userspace and fails
> > > > in a kernel paging request. The system is after the oops in a state
> > > > where no hid commands is sent anymore and only a boot can fix the
> > > > system.
> > > >
> > > > Keywords: usbhid hid
> > > >
> > > > Kernel version: Linux version 3.8.13-03081301-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201305311535 SMP Fri May 31 19:44:30 UTC 2013
> > > >
> > > > Oopses:
> > > > http://paste.debian.net/24305
> > > > http://paste.debian.net/24306
> > > > http://paste.debian.net/24307
> > > >
> > > > Code:
> > > > The error is triggered by:
> > > > ioctl(fd,HIDIOCSUSAGES, &ref_multi_u);
> > > > ioctl(fd,HIDIOCSREPORT, &rep_info_u);
> > > >
> > > > Notes:
> > > > It is very hard to reproduce so seems like race condition…
> > > >
> > > > Any tips to resolve/workaround this issue is appreciated and please
> > > > let me know if my information is incomplete (This is my first kernel
> > > > bug report)
> > >
> > >
> > > Any chance you can try a supported kernel, like 3.10.6 or 3.11-rc5 to
> > > see if that also causes problems? We can't do anything with
> > > distro-specific kernel releases like your 3.8.13 release from Ubuntu,
> > > sorry.
> >
> >
> > I've now tried with kernel 3.10.6 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.6-saucy/) and I can trigger the same issue on this kernel.
> >
> > Here is a paste from last Oops on this kernel:
> > http://paste.debian.net/24993/
> >
> > I am also using usbmon to monitor the usb bus traffic, but cannot see anything that should cause the driver to Oops.
> >
> > Is there any way to find out what can trigger this issue?
--
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
* [PATCH -next] HID: use module_hid_driver() to simplify the code
From: Wei Yongjun @ 2013-08-23 3:06 UTC (permalink / raw)
To: jkosina; +Cc: yongjun_wei, linux-input
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
module_hid_driver() makes the code simpler by eliminating
boilerplate code.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/hid/hid-xinmo.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/hid/hid-xinmo.c b/drivers/hid/hid-xinmo.c
index 6153e50..7df5227 100644
--- a/drivers/hid/hid-xinmo.c
+++ b/drivers/hid/hid-xinmo.c
@@ -57,16 +57,5 @@ static struct hid_driver xinmo_driver = {
.event = xinmo_event
};
-static int __init xinmo_init(void)
-{
- return hid_register_driver(&xinmo_driver);
-}
-
-static void __exit xinmo_exit(void)
-{
- hid_unregister_driver(&xinmo_driver);
-}
-
-module_init(xinmo_init);
-module_exit(xinmo_exit);
+module_hid_driver(xinmo_driver);
MODULE_LICENSE("GPL");
^ permalink raw reply related
* [PATCH] Input: as5011 - fix error return code in as5011_probe()
From: Wei Yongjun @ 2013-08-23 2:54 UTC (permalink / raw)
To: dmitry.torokhov, wfp5p, broonie, shubhrajyoti, javier
Cc: yongjun_wei, linux-input
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/input/joystick/as5011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/as5011.c b/drivers/input/joystick/as5011.c
index 121cd63..262ebe2 100644
--- a/drivers/input/joystick/as5011.c
+++ b/drivers/input/joystick/as5011.c
@@ -288,6 +288,7 @@ static int as5011_probe(struct i2c_client *client,
if (irq < 0) {
dev_err(&client->dev,
"Failed to get irq number for button gpio\n");
+ error = irq;
goto err_free_button_gpio;
}
^ permalink raw reply related
* [PATCH] Input: wacom - fix error return code in wacom_probe()
From: Wei Yongjun @ 2013-08-23 2:53 UTC (permalink / raw)
To: dmitry.torokhov, killertofu, pinglinux, chris, fengguang.wu
Cc: yongjun_wei, linux-input
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the urb submit error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/input/tablet/wacom_sys.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index aaf23ae..7eeac61 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -1366,7 +1366,8 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
usb_set_intfdata(intf, wacom);
if (features->quirks & WACOM_QUIRK_MONITOR) {
- if (usb_submit_urb(wacom->irq, GFP_KERNEL))
+ error = usb_submit_urb(wacom->irq, GFP_KERNEL);
+ if (error)
goto fail5;
}
^ permalink raw reply related
* [PATCH 3/3] Input: wacom - Send proper tablet state info when pen leaves proximity
From: Jason Gerecke @ 2013-08-23 1:15 UTC (permalink / raw)
To: linuxwacom-devel, linux-input, pinglinux; +Cc: Jason Gerecke
In-Reply-To: <1377220537-1474-1-git-send-email-killertofu@gmail.com>
The EMR sensor of Intuos4 and newer devices can send a packet with
0x20 in its second byte which contains only location information.
This packet is sent when the pen is too far away to reliably obtain
other information. Because only the location is updated userspace
will continue to see stale information for other values, most notably
TOUCH, PRESSURE, and DISTANCE.
This patch ensures userspace is not left with stale device state
information when the pen re-enters proximity (possibly leading to
the assumption the pen is still in contact even though it is
actually hovering).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_wac.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 869e9c9..f67a75a 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -425,6 +425,13 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
(features->type == WACOM_21UX2))
return 1;
+ /* Range Report */
+ if ((data[1] & 0xfe) == 0x20) {
+ input_report_key(input, BTN_TOUCH, 0);
+ input_report_abs(input, ABS_PRESSURE, 0);
+ input_report_abs(input, ABS_DISTANCE, wacom->features.distance_max);
+ }
+
/* Exit report */
if ((data[1] & 0xfe) == 0x80) {
if (features->quirks == WACOM_QUIRK_MULTI_INPUT)
--
1.8.3.4
^ permalink raw reply related
* [PATCH 2/3] Input: wacom - Provide a range for the ABS_MISC axis
From: Jason Gerecke @ 2013-08-23 1:15 UTC (permalink / raw)
To: linuxwacom-devel, linux-input, pinglinux; +Cc: Jason Gerecke
In-Reply-To: <1377220537-1474-1-git-send-email-killertofu@gmail.com>
Android marks found axes as 'valid' only if they have a minimum
and maximum value that aren't equal. Since we don't actually
assign any range information for ABS_MISC, Android doesn't bother
to mark it such. This prevents userspace from being able to make
use of tool serial information.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_wac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 8ccfe91..869e9c9 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1468,6 +1468,8 @@ static void wacom_abs_set_axis(struct input_dev *input_dev,
{
struct wacom_features *features = &wacom_wac->features;
+ input_set_abs_params(input_dev, ABS_MISC, INT_MIN, INT_MAX, 0, 0);
+
if (features->device_type == BTN_TOOL_PEN) {
input_set_abs_params(input_dev, ABS_X, 0, features->x_max,
features->x_fuzz, 0);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 1/3] Input: wacom - Support EMR and MFT sensors of Cintiq Companion Hybrid
From: Jason Gerecke @ 2013-08-23 1:15 UTC (permalink / raw)
To: linuxwacom-devel, linux-input, pinglinux; +Cc: Jason Gerecke
Adds support for the sensors integrated in to the Cintiq Companion
Hybrid. These sensors use by-and-large the same protocol as the
Cintiq 24HD touch.
NOTE: The ExpressKeys on the Cintiq Companion Hybrid are wired to
both the EMR controller and CPU GPIO pins. It may be necessary to
disable their functionality in this driver if building a custom
Android kernel for this device (lest two events be sent to userspace
for every button press).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_sys.c | 2 +-
drivers/input/tablet/wacom_wac.c | 49 +++++++++++++++++++++++++++++++++++++++-
drivers/input/tablet/wacom_wac.h | 1 +
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 1ad3e07..8fa7af7 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -548,7 +548,7 @@ static int wacom_query_tablet_data(struct usb_interface *intf, struct wacom_feat
/* MT Tablet PC touch */
return wacom_set_device_mode(intf, 3, 4, 4);
}
- else if (features->type == WACOM_24HDT) {
+ else if (features->type == WACOM_24HDT || features->type == ASTERIX) {
return wacom_set_device_mode(intf, 18, 3, 2);
}
} else if (features->device_type == BTN_TOOL_PEN) {
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 541197b..8ccfe91 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -475,7 +475,7 @@ static void wacom_intuos_general(struct wacom_wac *wacom)
/* general pen packet */
if ((data[1] & 0xb8) == 0xa0) {
t = (data[6] << 2) | ((data[7] >> 6) & 3);
- if (features->type >= INTUOS4S && features->type <= WACOM_24HD) {
+ if (features->type >= INTUOS4S && features->type <= ASTERIX) {
t = (t << 1) | (data[1] & 1);
}
input_report_abs(input, ABS_PRESSURE, t);
@@ -619,6 +619,25 @@ static int wacom_intuos_irq(struct wacom_wac *wacom)
} else {
input_report_abs(input, ABS_MISC, 0);
}
+ } else if (features->type == ASTERIX) {
+ /*
+ * Do not send hardware buttons under Android. They
+ * are already sent to the system through GPIO (and
+ * have different meaning).
+ */
+
+#if 1
+ input_report_key(input, BTN_1, (data[4] & 0x01));
+ input_report_key(input, BTN_2, (data[4] & 0x02));
+ input_report_key(input, BTN_3, (data[4] & 0x04));
+ input_report_key(input, BTN_4, (data[4] & 0x08));
+
+ input_report_key(input, BTN_5, (data[4] & 0x10)); // Right
+ input_report_key(input, BTN_6, (data[4] & 0x20)); // Up
+ input_report_key(input, BTN_7, (data[4] & 0x40)); // Left
+ input_report_key(input, BTN_8, (data[4] & 0x80)); // Down
+ input_report_key(input, BTN_0, (data[3] & 0x01)); // Center
+#endif
} else if (features->type >= INTUOS5S && features->type <= INTUOS5L) {
int i;
@@ -1325,6 +1344,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
case WACOM_22HD:
case WACOM_24HD:
case DTK:
+ case ASTERIX:
sync = wacom_intuos_irq(wacom_wac);
break;
@@ -1763,6 +1783,24 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
0, 0);
}
break;
+
+ case ASTERIX:
+ __set_bit(BTN_1, input_dev->keybit);
+ __set_bit(BTN_2, input_dev->keybit);
+ __set_bit(BTN_3, input_dev->keybit);
+ __set_bit(BTN_4, input_dev->keybit);
+
+ __set_bit(BTN_5, input_dev->keybit);
+ __set_bit(BTN_6, input_dev->keybit);
+ __set_bit(BTN_7, input_dev->keybit);
+ __set_bit(BTN_8, input_dev->keybit);
+ __set_bit(BTN_0, input_dev->keybit);
+
+ input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
+ __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
+
+ wacom_setup_cintiq(wacom_wac);
+ break;
}
return 0;
}
@@ -2117,6 +2155,13 @@ static const struct wacom_features wacom_features_0xDF =
static const struct wacom_features wacom_features_0x6004 =
{ "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x0307 =
+ { "Wacom ISDv5 307", WACOM_PKGLEN_INTUOS, 59552, 33848, 2047,
+ 63, ASTERIX, WACOM_INTUOS3_RES, WACOM_INTUOS3_RES,
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x309 };
+static const struct wacom_features wacom_features_0x0309 =
+ { "Wacom ISDv5 309", .type = WACOM_24HDT, /* Touch */
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x0307, .touch_max = 10 };
#define USB_DEVICE_WACOM(prod) \
USB_DEVICE(USB_VENDOR_ID_WACOM, prod), \
@@ -2247,6 +2292,8 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0xF8) },
{ USB_DEVICE_DETAILED(0xF6, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_WACOM(0xFA) },
+ { USB_DEVICE_WACOM(0x0307) },
+ { USB_DEVICE_DETAILED(0x0309, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_LENOVO(0x6004) },
{ }
};
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index dfc9e08..f47a5c1 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -80,6 +80,7 @@ enum {
WACOM_22HD,
DTK,
WACOM_24HD,
+ ASTERIX,
CINTIQ,
WACOM_BEE,
WACOM_13HD,
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH v3 0/3] HID: Win 8 multitouch panels detection in core
From: Henrik Rydberg @ 2013-08-22 17:55 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input, linux-kernel
In-Reply-To: <1377175869-5336-1-git-send-email-benjamin.tissoires@redhat.com>
Hi Benjamin,
thanks for the patches, it all looks fine now.
> this is the v3 of this patch series.
>
> Srinivas, I still did not added your tested-by as I made minors modifications of
> the patches 1 and 2. Now only the patch 1 will impact sensor_hub, and patch 2
> will not impact this. Maybe just wait for Henrik to put his "Reviewed-by" before
> giving one last test.
Here goes:
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Cheers,
Henrik
^ permalink raw reply
* Re: [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock
From: Jason A. Donenfeld @ 2013-08-22 17:29 UTC (permalink / raw)
To: Matthew Garrett
Cc: linux-acpi, linux-input, linux-kernel, mjg, rjw, len.brown, dtor
In-Reply-To: <20130822153900.GA2878@srcf.ucam.org>
On Thu, Aug 22, 2013 at 5:39 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> I think there's a risk of user confusion here, in that it's now possible
> for the mic mute light to be lit despite the internal microphone still
> being active. That seems like surprising behaviour.
Yeah, that is a legitimate concern. Patches 1/3 [1] and 2/3 [2]
clearly make sense, as they're generic and don't really suggest any
new behavior.
But setting this behavior here as the default could indeed be a bit
unexpected. I think it's fair to reject this patch (3/3), but accept
the first two. Tweakers who have the same early boot caps-lock LED
needs as me can simply put this in their initramfs after 1/3 and 2/3
are applied:
# echo caps-lock >
/sys/devices/platform/thinkpad_acpi/leds/tpacpi\:\:micmute/trigger
Jason
[1] https://lkml.org/lkml/2013/8/22/310
[2] https://lkml.org/lkml/2013/8/22/313
^ permalink raw reply
* Re: [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock
From: Matthew Garrett @ 2013-08-22 15:39 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-acpi, linux-input, linux-kernel, mjg, rjw, len.brown, dtor
In-Reply-To: <1377180132-4933-3-git-send-email-Jason@zx2c4.com>
On Thu, Aug 22, 2013 at 04:02:12PM +0200, Jason A. Donenfeld wrote:
> Thinkpads with a micmute LED do not have a capslock LED. The micmute LED
> is currently not used by any piece of Linux kernel land or user land. It
> seems reasonable to hook it up to caps lock, at least by default, so
> users can have some degree of functionality.
I think there's a risk of user confusion here, in that it's now possible
for the mic mute light to be lit despite the internal microphone still
being active. That seems like surprising behaviour.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH 3/3] thinkpad_acpi: Wire unused micmute LED to capslock
From: Jason A. Donenfeld @ 2013-08-22 14:02 UTC (permalink / raw)
To: linux-acpi, linux-input, linux-kernel
Cc: mjg, rjw, len.brown, dtor, Jason A. Donenfeld
In-Reply-To: <1377180132-4933-1-git-send-email-Jason@zx2c4.com>
Thinkpads with a micmute LED do not have a capslock LED. The micmute LED
is currently not used by any piece of Linux kernel land or user land. It
seems reasonable to hook it up to caps lock, at least by default, so
users can have some degree of functionality.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/platform/x86/thinkpad_acpi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 33b23cb..708fdb8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5235,6 +5235,10 @@ static int __init tpacpi_init_led(unsigned int led)
tpacpi_leds[led].led_classdev.name = tpacpi_led_names[led];
+ /* Special case wiring micmute to caps-lock by default. */
+ if (led == 14)
+ tpacpi_leds[led].led_classdev.default_trigger = "caps-lock";
+
INIT_WORK(&tpacpi_leds[led].work, led_set_status_worker);
rc = led_classdev_register(&tpacpi_pdev->dev,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] Input: atkbd - add LED triggers for keyboard state
From: Jason A. Donenfeld @ 2013-08-22 14:02 UTC (permalink / raw)
To: linux-acpi, linux-input, linux-kernel
Cc: mjg, rjw, len.brown, dtor, Jason A. Donenfeld
Many new laptop keyboards aren't shipping with LEDs in the keys for
caps lock, num lock, and scroll lock. They do, however, ship with many LEDs
for specialized functions that mostly go non-utilized by any current
Linux drivers. Having a caps lock LED is very helpful in early boot full
disk encryption, where a fancy GUI is not available to show that caps
lock is activated.
This patch wires in the caps, num, and scroll lock states of the
keyboard into the generic LED trigger subsystem, so that integrators can
have different LEDs activated on caps/num/scroll lock state changes.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/input/keyboard/atkbd.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..15061bf 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -28,6 +28,7 @@
#include <linux/libps2.h>
#include <linux/mutex.h>
#include <linux/dmi.h>
+#include <linux/leds.h>
#define DRIVER_DESC "AT and PS/2 keyboard driver"
@@ -302,6 +303,12 @@ static const unsigned int xl_table[] = {
ATKBD_RET_NAK, ATKBD_RET_HANJA, ATKBD_RET_HANGEUL,
};
+#ifdef CONFIG_LEDS_TRIGGERS
+struct led_trigger *capsl_led_trigger = 0;
+struct led_trigger *numl_led_trigger = 0;
+struct led_trigger *scrolll_led_trigger = 0;
+#endif
+
/*
* Checks if we should mangle the scancode to extract 'release' bit
* in translated mode.
@@ -559,6 +566,12 @@ static int atkbd_set_leds(struct atkbd *atkbd)
if (ps2_command(&atkbd->ps2dev, param, ATKBD_CMD_SETLEDS))
return -1;
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_event(capsl_led_trigger, test_bit(LED_CAPSL, dev->led) ? LED_FULL : LED_OFF);
+ led_trigger_event(numl_led_trigger, test_bit(LED_NUML, dev->led) ? LED_FULL : LED_OFF);
+ led_trigger_event(scrolll_led_trigger, test_bit(LED_SCROLLL, dev->led) ? LED_FULL : LED_OFF);
+#endif
+
if (atkbd->extra) {
param[0] = 0;
param[1] = (test_bit(LED_COMPOSE, dev->led) ? 0x01 : 0)
@@ -1781,12 +1794,25 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
static int __init atkbd_init(void)
{
dmi_check_system(atkbd_dmi_quirk_table);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple("caps-lock", &capsl_led_trigger);
+ led_trigger_register_simple("num-lock", &numl_led_trigger);
+ led_trigger_register_simple("scroll-lock", &scrolll_led_trigger);
+#endif
return serio_register_driver(&atkbd_drv);
}
static void __exit atkbd_exit(void)
{
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_unregister_simple(capsl_led_trigger);
+ capsl_led_trigger = 0;
+ led_trigger_unregister_simple(numl_led_trigger);
+ numl_led_trigger = 0;
+ led_trigger_unregister_simple(scrolll_led_trigger);
+ scrolll_led_trigger = 0;
+#endif
serio_unregister_driver(&atkbd_drv);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] thinkpad_acpi: Support micmute LED
From: Jason A. Donenfeld @ 2013-08-22 14:02 UTC (permalink / raw)
To: linux-acpi, linux-input, linux-kernel
Cc: mjg, rjw, len.brown, dtor, Jason A. Donenfeld
In-Reply-To: <1377180132-4933-1-git-send-email-Jason@zx2c4.com>
The micmute LED is currently unused. This patch allows it to be hooked
up to various LED triggers.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/platform/x86/thinkpad_acpi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 54d31c0..33b23cb 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5050,8 +5050,10 @@ static const char * const tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
"tpacpi::unknown_led2",
"tpacpi::unknown_led3",
"tpacpi::thinkvantage",
+ "tpacpi::unknown_led4",
+ "tpacpi::micmute"
};
-#define TPACPI_SAFE_LEDS 0x1081U
+#define TPACPI_SAFE_LEDS 0x5081U
static inline bool tpacpi_is_led_restricted(const unsigned int led)
{
@@ -5274,7 +5276,7 @@ static const struct tpacpi_quirk led_useful_qtable[] __initconst = {
{ /* Lenovo */
.vendor = PCI_VENDOR_ID_LENOVO,
.bios = TPACPI_MATCH_ANY, .ec = TPACPI_MATCH_ANY,
- .quirks = 0x1fffU,
+ .quirks = 0x5fffU,
},
{ /* IBM ThinkPads with no EC version string */
.vendor = PCI_VENDOR_ID_IBM,
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 3/3] HID: do not init input reports for Win 8 multitouch devices
From: Benjamin Tissoires @ 2013-08-22 12:51 UTC (permalink / raw)
To: Benjamin Tissoires, Henrik Rydberg, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input, linux-kernel
In-Reply-To: <1377175869-5336-1-git-send-email-benjamin.tissoires@redhat.com>
Some multitouch screens do not like to be polled for input reports.
However, the Win8 spec says that all touches should be sent during
each report, making the initialization of reports unnecessary.
The Win7 spec is less precise, so do not use this for those devices.
Add the quirk HID_QUIRK_NO_INIT_INPUT_REPORTS so that we do not have to
introduce a quirk for each problematic device. This quirk makes the driver
behave the same way the Win 8 does. It actually retrieves the features,
but not the inputs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
no changes in v3
no changes in v2
drivers/hid/hid-multitouch.c | 12 ++++++++++++
drivers/hid/usbhid/hid-core.c | 11 ++++++++---
include/linux/hid.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index c28ef86..ac28f08 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -951,6 +951,18 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
hdev->quirks |= HID_QUIRK_MULTI_INPUT;
hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
+ /*
+ * Handle special quirks for Windows 8 certified devices.
+ */
+ if (id->group == HID_GROUP_MULTITOUCH_WIN_8)
+ /*
+ * Some multitouch screens do not like to be polled for input
+ * reports. Fortunately, the Win8 spec says that all touches
+ * should be sent during each report, making the initialization
+ * of input reports unnecessary.
+ */
+ hdev->quirks |= HID_QUIRK_NO_INIT_INPUT_REPORTS;
+
td = devm_kzalloc(&hdev->dev, sizeof(struct mt_device), GFP_KERNEL);
if (!td) {
dev_err(&hdev->dev, "cannot allocate multitouch data\n");
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index bd38cdf..44df131 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -750,12 +750,17 @@ void usbhid_init_reports(struct hid_device *hid)
{
struct hid_report *report;
struct usbhid_device *usbhid = hid->driver_data;
+ struct hid_report_enum *report_enum;
int err, ret;
- list_for_each_entry(report, &hid->report_enum[HID_INPUT_REPORT].report_list, list)
- usbhid_submit_report(hid, report, USB_DIR_IN);
+ if (!(hid->quirks & HID_QUIRK_NO_INIT_INPUT_REPORTS)) {
+ report_enum = &hid->report_enum[HID_INPUT_REPORT];
+ list_for_each_entry(report, &report_enum->report_list, list)
+ usbhid_submit_report(hid, report, USB_DIR_IN);
+ }
- list_for_each_entry(report, &hid->report_enum[HID_FEATURE_REPORT].report_list, list)
+ report_enum = &hid->report_enum[HID_FEATURE_REPORT];
+ list_for_each_entry(report, &report_enum->report_list, list)
usbhid_submit_report(hid, report, USB_DIR_IN);
err = 0;
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 24f1197..d421848 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -283,6 +283,7 @@ struct hid_item {
#define HID_QUIRK_MULTI_INPUT 0x00000040
#define HID_QUIRK_HIDINPUT_FORCE 0x00000080
#define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
+#define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x00000200
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
#define HID_QUIRK_FULLSPEED_INTERVAL 0x10000000
#define HID_QUIRK_NO_INIT_REPORTS 0x20000000
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/3] HID: detect Win 8 multitouch devices in core
From: Benjamin Tissoires @ 2013-08-22 12:51 UTC (permalink / raw)
To: Benjamin Tissoires, Henrik Rydberg, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input, linux-kernel
In-Reply-To: <1377175869-5336-1-git-send-email-benjamin.tissoires@redhat.com>
Detecting Win 8 multitouch devices in core allows us to set quirks
before the device is parsed through hid_hw_start().
It also simplifies the detection of those devices in hid-multitouch and
makes the handling of those devices cleaner.
As Win 8 multitouch panels are in the group multitouch and rely on a
special feature to be detected, this patch adds a bitfield in the parser.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
changes in v3:
- removed ugly #define #undef :)
- add back scan_flags in hid_parser
- simpler post processing of Win 8 certified multitouch panels
- amended commit message
changes in v2:
- moved "flags" processing here
- do not introduce parser->flags, but use hid->group as a temporary flag placeholder
- #define and #undef HID_FLAG_* in hid-core.c instead of hid.h
- amended commit message
drivers/hid/hid-core.c | 16 ++++++++++++++++
drivers/hid/hid-multitouch.c | 24 +++++++++++-------------
include/linux/hid.h | 4 ++++
3 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9fc1220..db99900 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -685,6 +685,13 @@ static void hid_scan_input_usage(struct hid_parser *parser, u32 usage)
hid->group = HID_GROUP_MULTITOUCH;
}
+static void hid_scan_feature_usage(struct hid_parser *parser, u32 usage)
+{
+ if (usage == 0xff0000c5 && parser->global.report_count == 256 &&
+ parser->global.report_size == 8)
+ parser->scan_flags |= HID_SCAN_FLAG_MT_WIN_8;
+}
+
static void hid_scan_collection(struct hid_parser *parser, unsigned type)
{
struct hid_device *hid = parser->device;
@@ -714,6 +721,8 @@ static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
case HID_MAIN_ITEM_TAG_OUTPUT:
break;
case HID_MAIN_ITEM_TAG_FEATURE:
+ for (i = 0; i < parser->local.usage_index; i++)
+ hid_scan_feature_usage(parser, parser->local.usage[i]);
break;
}
@@ -757,6 +766,13 @@ static int hid_scan_report(struct hid_device *hid)
while ((start = fetch_item(start, end, &item)) != NULL)
dispatch_type[item.type](parser, &item);
+ /*
+ * Handle special flags set during scanning.
+ */
+ if ((parser->scan_flags & HID_SCAN_FLAG_MT_WIN_8) &&
+ (hid->group == HID_GROUP_MULTITOUCH))
+ hid->group = HID_GROUP_MULTITOUCH_WIN_8;
+
vfree(parser);
return 0;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 0fe00e2..c28ef86 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -133,6 +133,7 @@ static void mt_post_parse(struct mt_device *td);
#define MT_CLS_NSMU 0x000a
#define MT_CLS_DUAL_CONTACT_NUMBER 0x0010
#define MT_CLS_DUAL_CONTACT_ID 0x0011
+#define MT_CLS_WIN_8 0x0012
/* vendor specific classes */
#define MT_CLS_3M 0x0101
@@ -205,6 +206,11 @@ static struct mt_class mt_classes[] = {
MT_QUIRK_CONTACT_CNT_ACCURATE |
MT_QUIRK_SLOT_IS_CONTACTID,
.maxcontacts = 2 },
+ { .name = MT_CLS_WIN_8,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_IGNORE_DUPLICATES |
+ MT_QUIRK_HOVERING |
+ MT_QUIRK_CONTACT_CNT_ACCURATE },
/*
* vendor specific classes
@@ -332,19 +338,6 @@ static void mt_feature_mapping(struct hid_device *hdev,
td->maxcontacts = td->mtclass.maxcontacts;
break;
- case 0xff0000c5:
- if (field->report_count == 256 && field->report_size == 8) {
- /* Win 8 devices need special quirks */
- __s32 *quirks = &td->mtclass.quirks;
- *quirks |= MT_QUIRK_ALWAYS_VALID;
- *quirks |= MT_QUIRK_IGNORE_DUPLICATES;
- *quirks |= MT_QUIRK_HOVERING;
- *quirks |= MT_QUIRK_CONTACT_CNT_ACCURATE;
- *quirks &= ~MT_QUIRK_NOT_SEEN_MEANS_UP;
- *quirks &= ~MT_QUIRK_VALID_IS_INRANGE;
- *quirks &= ~MT_QUIRK_VALID_IS_CONFIDENCE;
- }
- break;
}
}
@@ -1346,6 +1339,11 @@ static const struct hid_device_id mt_devices[] = {
/* Generic MT device */
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) },
+
+ /* Generic Win 8 certified MT device */
+ { .driver_data = MT_CLS_WIN_8,
+ HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH_WIN_8,
+ HID_ANY_ID, HID_ANY_ID) },
{ }
};
MODULE_DEVICE_TABLE(hid, mt_devices);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 5a4e789..24f1197 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -295,6 +295,7 @@ struct hid_item {
#define HID_GROUP_GENERIC 0x0001
#define HID_GROUP_MULTITOUCH 0x0002
#define HID_GROUP_SENSOR_HUB 0x0003
+#define HID_GROUP_MULTITOUCH_WIN_8 0x0004
/*
* This is the global environment of the parser. This information is
@@ -533,6 +534,8 @@ static inline void hid_set_drvdata(struct hid_device *hdev, void *data)
#define HID_GLOBAL_STACK_SIZE 4
#define HID_COLLECTION_STACK_SIZE 4
+#define HID_SCAN_FLAG_MT_WIN_8 0x00000001
+
struct hid_parser {
struct hid_global global;
struct hid_global global_stack[HID_GLOBAL_STACK_SIZE];
@@ -541,6 +544,7 @@ struct hid_parser {
unsigned collection_stack[HID_COLLECTION_STACK_SIZE];
unsigned collection_stack_ptr;
struct hid_device *device;
+ unsigned scan_flags;
};
struct hid_class_descriptor {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 1/3] HID: Use hid_parser for pre-scanning the report descriptors
From: Benjamin Tissoires @ 2013-08-22 12:51 UTC (permalink / raw)
To: Benjamin Tissoires, Henrik Rydberg, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input, linux-kernel
In-Reply-To: <1377175869-5336-1-git-send-email-benjamin.tissoires@redhat.com>
The Win 8 detection is sufficiently complex to warrant use of the full
parser code, in spite of the inferred memory usage. Therefore, we can use
the existing HID parser in hid-core for hid_scan_report() by re-using the
code from hid_open_report(). hid_parser_global, hid_parser_local and
hid_parser_reserved does not have any side effects. We just need to
reimplement the MAIN_ITEM callback to have a proper parsing without side
effects.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
changes in v3:
- remove one remnant duplicate message
- amended commit message
- re-add initializer of hid->group (set to HID_GROUP_GENERIC)
changes in v2:
- moved "flags" processing in patch 2/3 (so use hid->group in this patch)
- hid_scan_report() is less verbose when errors are found in the descriptor
- hid_scan_report() is tolerant to parsing errors
- fixed usage_page handling in hid_scan_collection(), which fixes sensors detection
- amended commit message
drivers/hid/hid-core.c | 102 +++++++++++++++++++++++++++++++------------------
1 file changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 3efe19f..9fc1220 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -677,12 +677,52 @@ static u8 *fetch_item(__u8 *start, __u8 *end, struct hid_item *item)
return NULL;
}
-static void hid_scan_usage(struct hid_device *hid, u32 usage)
+static void hid_scan_input_usage(struct hid_parser *parser, u32 usage)
{
+ struct hid_device *hid = parser->device;
+
if (usage == HID_DG_CONTACTID)
hid->group = HID_GROUP_MULTITOUCH;
}
+static void hid_scan_collection(struct hid_parser *parser, unsigned type)
+{
+ struct hid_device *hid = parser->device;
+
+ if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
+ type == HID_COLLECTION_PHYSICAL)
+ hid->group = HID_GROUP_SENSOR_HUB;
+}
+
+static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
+{
+ __u32 data;
+ int i;
+
+ data = item_udata(item);
+
+ switch (item->tag) {
+ case HID_MAIN_ITEM_TAG_BEGIN_COLLECTION:
+ hid_scan_collection(parser, data & 0xff);
+ break;
+ case HID_MAIN_ITEM_TAG_END_COLLECTION:
+ break;
+ case HID_MAIN_ITEM_TAG_INPUT:
+ for (i = 0; i < parser->local.usage_index; i++)
+ hid_scan_input_usage(parser, parser->local.usage[i]);
+ break;
+ case HID_MAIN_ITEM_TAG_OUTPUT:
+ break;
+ case HID_MAIN_ITEM_TAG_FEATURE:
+ break;
+ }
+
+ /* Reset the local parser environment */
+ memset(&parser->local, 0, sizeof(parser->local));
+
+ return 0;
+}
+
/*
* Scan a report descriptor before the device is added to the bus.
* Sets device groups and other properties that determine what driver
@@ -690,48 +730,34 @@ static void hid_scan_usage(struct hid_device *hid, u32 usage)
*/
static int hid_scan_report(struct hid_device *hid)
{
- unsigned int page = 0, delim = 0;
+ struct hid_parser *parser;
+ struct hid_item item;
__u8 *start = hid->dev_rdesc;
__u8 *end = start + hid->dev_rsize;
- unsigned int u, u_min = 0, u_max = 0;
- struct hid_item item;
+ static int (*dispatch_type[])(struct hid_parser *parser,
+ struct hid_item *item) = {
+ hid_scan_main,
+ hid_parser_global,
+ hid_parser_local,
+ hid_parser_reserved
+ };
+
+ parser = vzalloc(sizeof(struct hid_parser));
+ if (!parser)
+ return -ENOMEM;
+ parser->device = hid;
hid->group = HID_GROUP_GENERIC;
- while ((start = fetch_item(start, end, &item)) != NULL) {
- if (item.format != HID_ITEM_FORMAT_SHORT)
- return -EINVAL;
- if (item.type == HID_ITEM_TYPE_GLOBAL) {
- if (item.tag == HID_GLOBAL_ITEM_TAG_USAGE_PAGE)
- page = item_udata(&item) << 16;
- } else if (item.type == HID_ITEM_TYPE_LOCAL) {
- if (delim > 1)
- break;
- u = item_udata(&item);
- if (item.size <= 2)
- u += page;
- switch (item.tag) {
- case HID_LOCAL_ITEM_TAG_DELIMITER:
- delim += !!u;
- break;
- case HID_LOCAL_ITEM_TAG_USAGE:
- hid_scan_usage(hid, u);
- break;
- case HID_LOCAL_ITEM_TAG_USAGE_MINIMUM:
- u_min = u;
- break;
- case HID_LOCAL_ITEM_TAG_USAGE_MAXIMUM:
- u_max = u;
- for (u = u_min; u <= u_max; u++)
- hid_scan_usage(hid, u);
- break;
- }
- } else if (page == HID_UP_SENSOR &&
- item.type == HID_ITEM_TYPE_MAIN &&
- item.tag == HID_MAIN_ITEM_TAG_BEGIN_COLLECTION &&
- (item_udata(&item) & 0xff) == HID_COLLECTION_PHYSICAL)
- hid->group = HID_GROUP_SENSOR_HUB;
- }
+ /*
+ * The parsing is simpler than the one in hid_open_report() as we should
+ * be robust against hid errors. Those errors will be raised by
+ * hid_open_report() anyway.
+ */
+ while ((start = fetch_item(start, end, &item)) != NULL)
+ dispatch_type[item.type](parser, &item);
+
+ vfree(parser);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 0/3] HID: Win 8 multitouch panels detection in core
From: Benjamin Tissoires @ 2013-08-22 12:51 UTC (permalink / raw)
To: Benjamin Tissoires, Henrik Rydberg, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input, linux-kernel
Hi guys,
this is the v3 of this patch series.
Srinivas, I still did not added your tested-by as I made minors modifications of
the patches 1 and 2. Now only the patch 1 will impact sensor_hub, and patch 2
will not impact this. Maybe just wait for Henrik to put his "Reviewed-by" before
giving one last test.
Cheers,
Benjamin
Changes in v3:
- remove one remnant duplicate message
- amended commit messages
- re-add initializer of hid->group (set to HID_GROUP_GENERIC)
- removed ugly #define #undef :)
- add back scan_flags in hid_parser
- simpler post processing of Win 8 certified multitouch panels
Changes in v2:
- moved "flags" processing in patch 2/3
- do not introduce parser->flags, but use hid->group as a temporary flag placeholder
- hid_scan_report() is less verbose when errors are found in the descriptor
- hid_scan_report() is tolerant to parsing errors
- fixed usage_page handling in hid_scan_collection(), which fixes sensors detection
- amended commit messages
- #define and #undef HID_FLAG_* in hid-core.c instead of hid.h
Benjamin Tissoires (3):
HID: Use hid_parser for pre-scanning the report descriptors
HID: detect Win 8 multitouch devices in core
HID: do not init input reports for Win 8 multitouch devices
drivers/hid/hid-core.c | 118 ++++++++++++++++++++++++++++--------------
drivers/hid/hid-multitouch.c | 36 ++++++++-----
drivers/hid/usbhid/hid-core.c | 11 ++--
include/linux/hid.h | 5 ++
4 files changed, 116 insertions(+), 54 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v1 23/49] hid: usbhid: prepare for enabling irq in complete()
From: Ming Lei @ 2013-08-22 12:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-usb, Oliver Neukum, Alan Stern, Ming Lei, Jiri Kosina,
linux-input
In-Reply-To: <1376756714-25479-24-git-send-email-ming.lei@canonical.com>
On Sun, Aug 18, 2013 at 12:24 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Complete() will be run with interrupt enabled, so change to
> spin_lock_irqsave().
>
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Jiri, could you review and give an Ack?
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v2 2/3] HID: detect Win 8 multitouch devices in core
From: Benjamin Tissoires @ 2013-08-22 12:01 UTC (permalink / raw)
To: Henrik Rydberg
Cc: Benjamin Tissoires, Jiri Kosina, Stephane Chatty,
Alexander Holler, Srinivas Pandruvada, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <20130821182654.GA3926@polaris.bitmath.org>
Hi Henrik,
On Wed, Aug 21, 2013 at 8:26 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Benjamin,
>
>> Detecting Win 8 multitouch devices in core allows us to set quirks
>> before the device is parsed through hid_hw_start().
>> It also simplifies the detection of those devices in hid-multitouch and
>> makes the handling of those devices cleaner.
>>
>> As Win 8 multitouch panels are in the group multitouch and rely on a
>> special feature to be detected, this patch also temporary convert
>> hid->group into a bitfield, before reverting it to the actual
>> group information. If we ever have more than 16 groups to detect,
>> we can then add a .flags field in hid_parser for instance, and then
>> use this to get the actual group.
>>
>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> ---
>>
>> changes in v2:
>> - moved "flags" processing here
>> - do not introduce parser->flags, but use hid->group as a temporary flag placeholder
>> - #define and #undef HID_FLAG_* in hid-core.c instead of hid.h
>> - amended commit message
>>
>> drivers/hid/hid-core.c | 41 +++++++++++++++++++++++++++++++++++++++--
>> drivers/hid/hid-multitouch.c | 24 +++++++++++-------------
>> include/linux/hid.h | 1 +
>> 3 files changed, 51 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index e072b15..c749966 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -677,12 +677,25 @@ static u8 *fetch_item(__u8 *start, __u8 *end, struct hid_item *item)
>> return NULL;
>> }
>>
>> +#define HID_FLAG_MULTITOUCH (1 << HID_GROUP_MULTITOUCH)
>> +#define HID_FLAG_WIN_8_CERTIFIED (1 << HID_GROUP_MULTITOUCH_WIN_8)
>> +#define HID_FLAG_SENSOR_HUB (1 << HID_GROUP_SENSOR_HUB)
>> +
>
> Why not use the existing defines directly? If you worry about being
Just because I need to check both ((1 << HID_GROUP_MULTITOUCH_WIN_8)
&& (1 << HID_GROUP_MULTITOUCH)) which starts being a little bit
difficult to read without the defines.
> able to combine bit positions in a simple mask rather than using the
> existing bitmask (which could be good), how about a priority list for
> the groups instead? My own preference would be to leave structure for
> the future to the future, and use a single state in the parser for the
> case you are adding.
I'd go with a scanning_flags (so a bitmask) in the parser. This will
allows us to add other special case later if required. I don't really
like the idea of having just a boolean is_win8 because IMO the name
should be more explicit, and this will encourage people to add various
flags in the parser.
>
>> static void hid_scan_input_usage(struct hid_parser *parser, u32 usage)
>> {
>> struct hid_device *hid = parser->device;
>>
>> if (usage == HID_DG_CONTACTID)
>> - hid->group = HID_GROUP_MULTITOUCH;
>> + hid->group |= HID_FLAG_MULTITOUCH;
>> +}
>
> Dynamic semantics, please no :-) My suggestion: leave this line be...
ok, will revert it
>
>> +
>> +static void hid_scan_feature_usage(struct hid_parser *parser, u32 usage)
>> +{
>> + struct hid_device *hid = parser->device;
>> +
>> + if (usage == 0xff0000c5 && parser->global.report_count == 256 &&
>> + parser->global.report_size == 8)
>> + hid->group |= HID_FLAG_WIN_8_CERTIFIED;
>
> And set 'parser->is_win8 = true' here.
>
Again, I'd prefer to go with "parser->scanning_flags |=
HID_SCAN_FLAG_WIN_8_MT_PANEL" (or sth better for the name).
>> }
>>
>> static void hid_scan_collection(struct hid_parser *parser, unsigned type)
>> @@ -691,7 +704,7 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
>>
>> if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
>> type == HID_COLLECTION_PHYSICAL)
>> - hid->group = HID_GROUP_SENSOR_HUB;
>> + hid->group |= HID_FLAG_SENSOR_HUB;
>
> Leave this...
ok
>
>> }
>>
>> static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
>> @@ -714,6 +727,8 @@ static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
>> case HID_MAIN_ITEM_TAG_OUTPUT:
>> break;
>> case HID_MAIN_ITEM_TAG_FEATURE:
>> + for (i = 0; i < parser->local.usage_index; i++)
>> + hid_scan_feature_usage(parser, parser->local.usage[i]);
>> break;
>> default:
>> hid_err(parser->device, "unknown main item tag 0x%x\n",
>> @@ -759,10 +774,32 @@ static int hid_scan_report(struct hid_device *hid)
>> while ((start = fetch_item(start, end, &item)) != NULL)
>> dispatch_type[item.type](parser, &item);
>>
>> + /*
>> + * Re-interprete the group field to keep the same group definitions than
>> + * we had in previous kernels.
>> + */
>> + switch (hid->group) {
>> + case HID_FLAG_MULTITOUCH:
>> + hid->group = HID_GROUP_MULTITOUCH;
>> + break;
>> + case HID_FLAG_MULTITOUCH | HID_FLAG_WIN_8_CERTIFIED:
>> + hid->group = HID_GROUP_MULTITOUCH_WIN_8;
>> + break;
>> + case HID_FLAG_SENSOR_HUB:
>> + hid->group = HID_GROUP_SENSOR_HUB;
>> + break;
>> + default:
>> + hid->group = HID_GROUP_GENERIC;
>> + }
>> +
>
> ... and replace this with 'if (parser->is_win8) hid->group = HID_GROUP_MULTITOUCH_WIN_8'.
The test should be:
if ((hid->group == HID_GROUP_MULTITOUCH) && (parser->scanning_flags &
HID_SCAN_FLAG_WIN_8_MT_PANEL))
>
>> vfree(parser);
>> return 0;
>> }
>>
>> +#undef HID_FLAG_MULTITOUCH
>> +#undef HID_FLAG_WIN_8_CERTIFIED
>> +#undef HID_FLAG_SENSOR_HUB
>> +
>
> No comment ;-)
alright. I tried :)
Cheers,
Benjamin
>
>> /**
>> * hid_parse_report - parse device report
>> *
>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>> index 0fe00e2..c28ef86 100644
>> --- a/drivers/hid/hid-multitouch.c
>> +++ b/drivers/hid/hid-multitouch.c
>> @@ -133,6 +133,7 @@ static void mt_post_parse(struct mt_device *td);
>> #define MT_CLS_NSMU 0x000a
>> #define MT_CLS_DUAL_CONTACT_NUMBER 0x0010
>> #define MT_CLS_DUAL_CONTACT_ID 0x0011
>> +#define MT_CLS_WIN_8 0x0012
>>
>> /* vendor specific classes */
>> #define MT_CLS_3M 0x0101
>> @@ -205,6 +206,11 @@ static struct mt_class mt_classes[] = {
>> MT_QUIRK_CONTACT_CNT_ACCURATE |
>> MT_QUIRK_SLOT_IS_CONTACTID,
>> .maxcontacts = 2 },
>> + { .name = MT_CLS_WIN_8,
>> + .quirks = MT_QUIRK_ALWAYS_VALID |
>> + MT_QUIRK_IGNORE_DUPLICATES |
>> + MT_QUIRK_HOVERING |
>> + MT_QUIRK_CONTACT_CNT_ACCURATE },
>>
>> /*
>> * vendor specific classes
>> @@ -332,19 +338,6 @@ static void mt_feature_mapping(struct hid_device *hdev,
>> td->maxcontacts = td->mtclass.maxcontacts;
>>
>> break;
>> - case 0xff0000c5:
>> - if (field->report_count == 256 && field->report_size == 8) {
>> - /* Win 8 devices need special quirks */
>> - __s32 *quirks = &td->mtclass.quirks;
>> - *quirks |= MT_QUIRK_ALWAYS_VALID;
>> - *quirks |= MT_QUIRK_IGNORE_DUPLICATES;
>> - *quirks |= MT_QUIRK_HOVERING;
>> - *quirks |= MT_QUIRK_CONTACT_CNT_ACCURATE;
>> - *quirks &= ~MT_QUIRK_NOT_SEEN_MEANS_UP;
>> - *quirks &= ~MT_QUIRK_VALID_IS_INRANGE;
>> - *quirks &= ~MT_QUIRK_VALID_IS_CONFIDENCE;
>> - }
>> - break;
>> }
>> }
>>
>> @@ -1346,6 +1339,11 @@ static const struct hid_device_id mt_devices[] = {
>>
>> /* Generic MT device */
>> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) },
>> +
>> + /* Generic Win 8 certified MT device */
>> + { .driver_data = MT_CLS_WIN_8,
>> + HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH_WIN_8,
>> + HID_ANY_ID, HID_ANY_ID) },
>> { }
>> };
>> MODULE_DEVICE_TABLE(hid, mt_devices);
>> diff --git a/include/linux/hid.h b/include/linux/hid.h
>> index 5a4e789..45b7f3f 100644
>> --- a/include/linux/hid.h
>> +++ b/include/linux/hid.h
>> @@ -295,6 +295,7 @@ struct hid_item {
>> #define HID_GROUP_GENERIC 0x0001
>> #define HID_GROUP_MULTITOUCH 0x0002
>> #define HID_GROUP_SENSOR_HUB 0x0003
>> +#define HID_GROUP_MULTITOUCH_WIN_8 0x0004
>>
>> /*
>> * This is the global environment of the parser. This information is
>> --
>> 1.8.3.1
>>
>
> Thanks,
> Henrik
^ permalink raw reply
* RE: [PATCH v3 0/3] Input: omap-keypad: Convert to threaded IRQ and cleanup
From: Smyrnov, Illia @ 2013-08-22 11:34 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Balbi, Felipe, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <1374681293-5320-1-git-send-email-illia.smyrnov@ti.com>
Dmitry,
should I take any additional action regarding these patches?
Best regards,
Illia Smyrnov
________________________________________
From: linux-kernel-owner@vger.kernel.org [linux-kernel-owner@vger.kernel.org] on behalf of Smyrnov, Illia
Sent: Wednesday, July 24, 2013 6:54 PM
To: Dmitry Torokhov
Cc: Balbi, Felipe; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; linux-omap@vger.kernel.org
Subject: [PATCH v3 0/3] Input: omap-keypad: Convert to threaded IRQ and cleanup
Replace unclear hardcoded values with bit field, convert to threaded IRQ and
clear interrupts when open the keypad.
Based on top of v3.11-rc2.
Tested on OMAP4 SDP.
Illia Smyrnov (3):
Input: omap-keypad: Cleanup - use bitfiled instead of hardcoded
values
Input: omap-keypad: Convert to threaded IRQ
Input: omap-keypad: Clear interrupts on open
drivers/input/keyboard/omap4-keypad.c | 57 +++++++++++++++++++--------------
1 files changed, 33 insertions(+), 24 deletions(-)
^ 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