* Re: [PATCH 9/9] Staging/iio: add TODO reminder
From: Jonathan Cameron @ 2013-10-01 11:14 UTC (permalink / raw)
To: Juergen Beisert, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
jic23-KWPb1pKIrIJaa/9Udqfwiw, linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379946998-23041-10-git-send-email-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 09/23/13 15:36, Juergen Beisert wrote:
> Some things have still to be done to the LRADC driver.
>
> Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> CC: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> CC: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
> CC: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
> CC: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> CC: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
Applied to the togreg branch of iio.git
Thanks.
Please check over the entire series as it was more than a little
fiddly to apply and I may well have messed it up!
Jonathan
> ---
> drivers/staging/iio/TODO | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO
> index 04c2326..c22a0ed 100644
> --- a/drivers/staging/iio/TODO
> +++ b/drivers/staging/iio/TODO
> @@ -13,6 +13,17 @@ Would be nice
> 3) Expand device set. Lots of other maxim adc's have very
> similar interfaces.
>
> +MXS LRADC driver:
> +This is a classic MFD device as it combines the following subdevices
> + - touchscreen controller (input subsystem related device)
> + - general purpose ADC channels
> + - battery voltage monitor (power subsystem related device)
> + - die temperature monitor (thermal management)
> +
> +At least the battery voltage and die temperature feature is required in-kernel
> +by a driver of the SoC's battery charging unit to avoid any damage to the
> +silicon and the battery.
> +
> TSL2561
> Would be nice
> 1) Open question of userspace vs kernel space balance when
>
^ permalink raw reply
* Re: [PATCH 9/9] Staging/iio: add TODO reminder
From: Jonathan Cameron @ 2013-10-01 11:21 UTC (permalink / raw)
To: Juergen Beisert, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
jic23-KWPb1pKIrIJaa/9Udqfwiw, linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <524AAEA8.4090106-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 10/01/13 12:14, Jonathan Cameron wrote:
> On 09/23/13 15:36, Juergen Beisert wrote:
>> Some things have still to be done to the LRADC driver.
>>
>> Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> CC: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> CC: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
>> CC: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>> CC: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> CC: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
> Applied to the togreg branch of iio.git
>
> Thanks.
>
> Please check over the entire series as it was more than a little
> fiddly to apply and I may well have messed it up!
There may be a delay on me pushing this out. Kernel.org isn't talking
to me right now for some reason.
>
> Jonathan
>> ---
>> drivers/staging/iio/TODO | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO
>> index 04c2326..c22a0ed 100644
>> --- a/drivers/staging/iio/TODO
>> +++ b/drivers/staging/iio/TODO
>> @@ -13,6 +13,17 @@ Would be nice
>> 3) Expand device set. Lots of other maxim adc's have very
>> similar interfaces.
>>
>> +MXS LRADC driver:
>> +This is a classic MFD device as it combines the following subdevices
>> + - touchscreen controller (input subsystem related device)
>> + - general purpose ADC channels
>> + - battery voltage monitor (power subsystem related device)
>> + - die temperature monitor (thermal management)
>> +
>> +At least the battery voltage and die temperature feature is required in-kernel
>> +by a driver of the SoC's battery charging unit to avoid any damage to the
>> +silicon and the battery.
>> +
>> TSL2561
>> Would be nice
>> 1) Open question of userspace vs kernel space balance when
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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: [PATCH 9/9] Staging/iio: add TODO reminder
From: Jonathan Cameron @ 2013-10-01 11:22 UTC (permalink / raw)
To: Juergen Beisert, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
jic23-KWPb1pKIrIJaa/9Udqfwiw, linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <524AB04C.4070409-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 10/01/13 12:21, Jonathan Cameron wrote:
> On 10/01/13 12:14, Jonathan Cameron wrote:
>> On 09/23/13 15:36, Juergen Beisert wrote:
>>> Some things have still to be done to the LRADC driver.
>>>
>>> Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>> CC: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> CC: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
>>> CC: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>>> CC: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>> CC: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
>> Applied to the togreg branch of iio.git
>>
>> Thanks.
>>
>> Please check over the entire series as it was more than a little
>> fiddly to apply and I may well have messed it up!
> There may be a delay on me pushing this out. Kernel.org isn't talking
> to me right now for some reason.
Hmm. Typical, it worked just after I sent this.
Anyhow, all there now.
>>
>> Jonathan
>>> ---
>>> drivers/staging/iio/TODO | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO
>>> index 04c2326..c22a0ed 100644
>>> --- a/drivers/staging/iio/TODO
>>> +++ b/drivers/staging/iio/TODO
>>> @@ -13,6 +13,17 @@ Would be nice
>>> 3) Expand device set. Lots of other maxim adc's have very
>>> similar interfaces.
>>>
>>> +MXS LRADC driver:
>>> +This is a classic MFD device as it combines the following subdevices
>>> + - touchscreen controller (input subsystem related device)
>>> + - general purpose ADC channels
>>> + - battery voltage monitor (power subsystem related device)
>>> + - die temperature monitor (thermal management)
>>> +
>>> +At least the battery voltage and die temperature feature is required in-kernel
>>> +by a driver of the SoC's battery charging unit to avoid any damage to the
>>> +silicon and the battery.
>>> +
>>> TSL2561
>>> Would be nice
>>> 1) Open question of userspace vs kernel space balance when
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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-iio" 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: weird hidraw behaviour
From: Manoj Chourasia @ 2013-10-01 11:43 UTC (permalink / raw)
To: Mika Westerberg; +Cc: linux-input@vger.kernel.org, Jiri Kosina
In-Reply-To: <20130924085606.GI28875@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
Hi Mika,
Can you please try the attached patch and see if it fixes this issue?
Thanks
-Manoj
-----Original Message-----
From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
Sent: Tuesday, September 24, 2013 2:26 PM
To: Jiri Kosina; Manoj Chourasia
Cc: linux-input@vger.kernel.org
Subject: Q: weird hidraw behaviour
Hi,
I noticed that after commit 212a871a393 (HID: hidraw: correctly deallocate memory on device disconnect) hidraw doesn't close the underlying hid device when the device node is closed last time.
For example I have a touch panel (HID over I2C) device with added debug prints in i2c_hid_open()/i2c_hid_close():
# od -x /dev/hidraw0
[ 41.363813] i2c_hid 1-004c: i2c_hid_power lvl:32
[ 41.368464] i2c_hid 1-004c: i2c_hid_set_power
[ 41.372831] i2c_hid 1-004c: __i2c_hid_command: cmd=54 01 00 08
[ 41.451455] i2c_hid 1-004c: i2c_hid_open
^C
# od -x /dev/hidraw0
[ 58.420928] i2c_hid 1-004c: i2c_hid_power lvl:32
[ 58.425577] i2c_hid 1-004c: i2c_hid_set_power
[ 58.429945] i2c_hid 1-004c: __i2c_hid_command: cmd=54 01 00 08
[ 58.525276] i2c_hid 1-004c: i2c_hid_open
^C
i2c_hid_close() is never called. Is this intended or am I missing something?
Thanks.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
[-- Attachment #2: HID-hidraw-close-underlying-device-at-removal-of-las.patch --]
[-- Type: application/octet-stream, Size: 1644 bytes --]
From 05b85899534eacce21db0b39b86beca61d7799c8 Mon Sep 17 00:00:00 2001
From: Manoj Chourasia <mchourasia@nvidia.com>
Date: Tue, 1 Oct 2013 15:39:00 +0530
Subject: [PATCH] HID: hidraw: close underlying device at removal of last
reader
Even though device exist bit is set the underlying
HW device should be closed when the last reader
of the device is closed i.e. open count drops to zero.
Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
---
drivers/hid/hidraw.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index dbfe300..4faf728 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -305,19 +305,27 @@ static int hidraw_fasync(int fd, struct file *file, int on)
static void drop_ref(struct hidraw *hidraw, int exists_bit)
{
if (exists_bit) {
- hid_hw_close(hidraw->hid);
hidraw->exist = 0;
- if (hidraw->open)
+ if (hidraw->open) {
+ hid_hw_close(hidraw->hid);
wake_up_interruptible(&hidraw->wait);
+ }
} else {
--hidraw->open;
}
- if (!hidraw->open && !hidraw->exist) {
- device_destroy(hidraw_class, MKDEV(hidraw_major, hidraw->minor));
- hidraw_table[hidraw->minor] = NULL;
- kfree(hidraw);
- }
+ if (!hidraw->open)
+ if (!hidraw->exist) {
+ device_destroy(hidraw_class,
+ MKDEV(hidraw_major, hidraw->minor));
+ hidraw_table[hidraw->minor] = NULL;
+ kfree(hidraw);
+ } else {
+ /* close device for last reader */
+ hid_hw_power(hidraw->hid, PM_HINT_NORMAL);
+ hid_hw_close(hidraw->hid);
+ }
+
}
static int hidraw_release(struct inode * inode, struct file * file)
--
1.7.9.5
^ permalink raw reply related
* Re: weird hidraw behaviour
From: Mika Westerberg @ 2013-10-01 12:43 UTC (permalink / raw)
To: Manoj Chourasia; +Cc: linux-input@vger.kernel.org, Jiri Kosina
In-Reply-To: <F1F6C959961EA744BBD5B8EEF8B8FEA16DDD19DD16@BGMAIL02.nvidia.com>
On Tue, Oct 01, 2013 at 05:13:16PM +0530, Manoj Chourasia wrote:
> Can you please try the attached patch and see if it fixes this issue?
Yes, that patch fixes the issue for me, thanks!
It introduces following warning, though:
drivers/hid/hidraw.c: In function ‘drop_ref’:
drivers/hid/hidraw.c:320:5: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
if (!hidraw->open)
--
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: weird hidraw behaviour
From: Manoj Chourasia @ 2013-10-01 13:18 UTC (permalink / raw)
To: Mika Westerberg; +Cc: linux-input@vger.kernel.org, Jiri Kosina
In-Reply-To: <20131001124326.GZ28875@intel.com>
Thanks Mika,
I will be fix the warning and post a patch for Jiri to review.
-Manoj
-----Original Message-----
From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
Sent: Tuesday, October 01, 2013 6:13 PM
To: Manoj Chourasia
Cc: linux-input@vger.kernel.org; Jiri Kosina
Subject: Re: weird hidraw behaviour
On Tue, Oct 01, 2013 at 05:13:16PM +0530, Manoj Chourasia wrote:
> Can you please try the attached patch and see if it fixes this issue?
Yes, that patch fixes the issue for me, thanks!
It introduces following warning, though:
drivers/hid/hidraw.c: In function ‘drop_ref’:
drivers/hid/hidraw.c:320:5: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
if (!hidraw->open)
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* RE: weird hidraw behaviour
From: Manoj Chourasia @ 2013-10-01 13:37 UTC (permalink / raw)
To: Mika Westerberg; +Cc: linux-input@vger.kernel.org, Jiri Kosina
In-Reply-To: <20131001124326.GZ28875@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
Hi Mika,
I have posted the patch in mailing list for review. Attaching it here too.
Please test it one more time as I have fixed the warning.
Regards
-Manoj
-----Original Message-----
From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
Sent: Tuesday, October 01, 2013 6:13 PM
To: Manoj Chourasia
Cc: linux-input@vger.kernel.org; Jiri Kosina
Subject: Re: weird hidraw behaviour
On Tue, Oct 01, 2013 at 05:13:16PM +0530, Manoj Chourasia wrote:
> Can you please try the attached patch and see if it fixes this issue?
Yes, that patch fixes the issue for me, thanks!
It introduces following warning, though:
drivers/hid/hidraw.c: In function ‘drop_ref’:
drivers/hid/hidraw.c:320:5: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
if (!hidraw->open)
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
[-- Attachment #2: PATCH-hidraw-close-underlying-device-at-removal-of-las.patch --]
[-- Type: application/octet-stream, Size: 1641 bytes --]
From b37519b65be0d51b90c5fc177c0dc0cd2f6358b1 Mon Sep 17 00:00:00 2001
From: Manoj Chourasia <mchourasia@nvidia.com>
Date: Tue, 1 Oct 2013 15:39:00 +0530
Subject: [PATCH] HID: hidraw: close underlying device at removal of last
reader
Even though device exist is set the underlying
HW device should be closed when the last reader
of the device is closed i.e. open count drops to zero.
Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
---
drivers/hid/hidraw.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index dbfe300..3c0dd44 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -305,19 +305,28 @@ static int hidraw_fasync(int fd, struct file *file, int on)
static void drop_ref(struct hidraw *hidraw, int exists_bit)
{
if (exists_bit) {
- hid_hw_close(hidraw->hid);
hidraw->exist = 0;
- if (hidraw->open)
+ if (hidraw->open) {
+ hid_hw_close(hidraw->hid);
wake_up_interruptible(&hidraw->wait);
+ }
} else {
--hidraw->open;
}
- if (!hidraw->open && !hidraw->exist) {
- device_destroy(hidraw_class, MKDEV(hidraw_major, hidraw->minor));
- hidraw_table[hidraw->minor] = NULL;
- kfree(hidraw);
+ if (!hidraw->open) {
+ if (!hidraw->exist) {
+ device_destroy(hidraw_class,
+ MKDEV(hidraw_major, hidraw->minor));
+ hidraw_table[hidraw->minor] = NULL;
+ kfree(hidraw);
+ } else {
+ /* close device for last reader */
+ hid_hw_power(hidraw->hid, PM_HINT_NORMAL);
+ hid_hw_close(hidraw->hid);
+ }
}
+
}
static int hidraw_release(struct inode * inode, struct file * file)
--
1.7.9.5
^ permalink raw reply related
* Re: weird hidraw behaviour
From: Mika Westerberg @ 2013-10-01 13:56 UTC (permalink / raw)
To: Manoj Chourasia; +Cc: linux-input@vger.kernel.org, Jiri Kosina
In-Reply-To: <F1F6C959961EA744BBD5B8EEF8B8FEA16DDD19DD44@BGMAIL02.nvidia.com>
On Tue, Oct 01, 2013 at 07:07:57PM +0530, Manoj Chourasia wrote:
> I have posted the patch in mailing list for review. Attaching it here too.
> Please test it one more time as I have fixed the warning.
Still works for me, thanks!
^ permalink raw reply
* Re: xpad input driver: Xbox 360 Wireless Adapter
From: David Herrmann @ 2013-10-01 14:34 UTC (permalink / raw)
To: Zachary Lund
Cc: linux-kernel, open list:HID CORE LAYER, Dmitry Torokhov,
Christoph Fritz, Marko Friedemann
In-Reply-To: <CAC24_3uGi8B_g7Jc0myOowdw2YgXP-UZLWMOUhiWbcgewvNEEA@mail.gmail.com>
Hi
On Tue, Oct 1, 2013 at 2:11 AM, Zachary Lund <admin@computerquip.com> wrote:
> I apologize for poor assumptions and lack of general knowledge
> concerning what I'm talking about. However, I feel I can still help on
> the subject.
>
> As to what device I'm talking about, I'm talking about the more
> properly termed "Xbox 360 Wireless Gaming Reciever". More information
> and a picture can be found here:
> http://www.microsoft.com/games/en-US/Hardware/Controllers/Pages/XboxWirelessGamingReceiverforWindows.aspx
Thanks for the link. Now I understand what you meant.
> Future references will refer the above device as "wireless reciever"
> and the opposing wired controller that requires no reciever as "wired
> controller".
> When I refer to the "xpad driver", I mean the USB driver sitting here:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/input/joystick/xpad.c
>
> To be clear, the wireless receiver connects to a USB port in the PC
> and interacts wirelessly with any Xbox 360 controller that can connect
> to the Xbox 360 console (but the driver doesn't need to know this).
> When a controller is "synced" with the wireless receiver, it sends
> events like normal over the corresponding USB interface via interrupt
> endpoints.
What exactly does the receiver provide to the host? Does it act as a
"USB Hub" and emulates USB hotplugging whenever you connect a device?
Or does it actually act as a single xbox-controller device and just
waits for a connected device to send the "connected" event? But see
below..
>>> Second, the driver acts strangely when setting the LED. It calls
>>> xpad_send_led_command during xpad_led_probe during xpad_probe but
>>> there's a chance that a controller might not even be connected if
>>> using the wireless adapter during that time!
>>
>>What? During xpad_probe() a device must be fully functional. What
>>adapter are your talking about?
>
> I apologize again for not explaining well enough. When the wireless
> receiver is connected, all 8 interfaces are probed immediately but a
> wireless controller may not actually be synced with the wireless
> receiver. Even if it were, the current method the xpad driver takes
> doesn't seem to work on the wireless receiver and leaves the
> controllers LED in a default "blinking" state.
..so to answer my question above: The device provides 8 static USB
interfaces with the VID/PID pre-configured to the host? And once a
real device connects to the hub, it simply starts the USB interaction
with the host? Sounds reasonable. But the linux driver might not have
been written to work with such a setup.
>>> The only way to seemingly
>>> tell if a controller is connected is by receiving the correct
>>> connection packets. If I use the correct packet structure (which I
>>> ripped almost directly from xboxdrv) and set the led after parsing a
>>> connection packet, the LED seemingly works fine!
>>
>>Sounds reasonable. Do all devices send the connection-packets? If yes,
>>feel free to send a patch which moves LED initialization after receipt
>>of this package.
>
> My inexperience comes into play here probably so take what I say with
> a grain of salt please. Whenever a controller is synced with the
> wireless reciever, the wireless receiver sends an interrupt packet
> containing 0x08 0x80 to the driver to say that a new controller is
> connected (which corresponds to the USB interface it was sent on,
> explained below) or 0x08 0x00 to say that it has disconnected. I
> believe there's already a patch available (not created by me) after
> further diving in the mailing list, although I cannot confirm whether
> it works or not as I've not tested it myself:
> https://lkml.org/lkml/2012/11/30/558
Yepp, this one looks good. Please test it and resend it if it fixes
your problems.
> To further explain, there are differences between the wireless
> receiver and wired controller concerning how it works. The wired
> controller seems to have only 4 USB interfaces (according to
> http://www.free60.org/GamePad) whereas the wireless receiver has 8. I
> cannot explain what the interfaces for the wired controller do but for
> the wireless receiver, all odd interfaces seem to deal with input
> events, LEDs, and anything to do with the actual controller. So
> interfaces 1, 3, 5, and 7 can represent a controller. All even
> interfaces (0, 2, 4, 6) seem to represent something else, probably a
> headset which I can't confirm or test. Either way, the driver doesn't
> support whatever these interfaces do so should xpad actually claim
> them? The patch mentioned above seems to also remove the out bulk
> endpoint sense it doesn't seem to be useful to any of the Xbox 360
> controllers including the wired ones. A lot of things I don't know
> myself. I apologize if I just confused the matter.
Sorry, but I don't have the device so I cannot really help here. You
need to reverse-engineer it yourself and patch the file. Sorry but I
don't know anyone actively working on it.
Problem is, this driver is quite old and supports a wide-range of
devices. Patches like the one mentioned above might break other
devices than yours. If you want your devices to be properly supported,
you need to either fix the drivers yourself and send patches or find
someone who does it for you, sorry..
If it's just your LED thing that broke, you might want to just
consider re-sending the SET-LED command after the configure-event.
Don't remove the old SET-LED but just resend it. This shouldn't break
other devices.
Regards
David
^ permalink raw reply
* [PATCH] HID: Added Holtek USB ID 04d9:a081 SHARKOON DarkGlider Gaming mouse
From: Anders F. U. Kiær @ 2013-10-01 17:22 UTC (permalink / raw)
To: jkosina; +Cc: linux-input, linux-kernel, Anders F. U. Kiær
Target: 3.11.2
Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON
DarkGlider Gaming mouse to use the same corrections of the report
descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES
at the same offsets in the reported descriptor.
Tested on the hardware.
Signed-off-by: Anders F. U. Kiær <ablacksheep@gmail.com>
---
drivers/hid/Kconfig | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-holtek-mouse.c | 4 ++++
drivers/hid/hid-ids.h | 1 +
4 files changed, 7 insertions(+)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 14ef6ab..750adde 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -241,6 +241,7 @@ config HID_HOLTEK
- Sharkoon Drakonia / Perixx MX-2000 gaming mice
- Tracer Sniper TRM-503 / NOVA Gaming Slider X200 /
Zalman ZM-GM1
+ - SHARKOON DarkGlider Gaming mouse
config HOLTEK_FF
bool "Holtek On Line Grip force feedback support"
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5956445..754cd59 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1600,6 +1600,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A04A) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A067) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HUION, USB_DEVICE_ID_HUION_580) },
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS2, USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ION, USB_DEVICE_ID_ICADE) },
diff --git a/drivers/hid/hid-holtek-mouse.c b/drivers/hid/hid-holtek-mouse.c
index 7e6db3c..e696566 100644
--- a/drivers/hid/hid-holtek-mouse.c
+++ b/drivers/hid/hid-holtek-mouse.c
@@ -27,6 +27,7 @@
* - USB ID 04d9:a067, sold as Sharkoon Drakonia and Perixx MX-2000
* - USB ID 04d9:a04a, sold as Tracer Sniper TRM-503, NOVA Gaming Slider X200
* and Zalman ZM-GM1
+ * - USB ID 04d9:a081, sold as SHARKOON DarkGlider Gaming mouse
*/
static __u8 *holtek_mouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
@@ -46,6 +47,7 @@ static __u8 *holtek_mouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
}
break;
case USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A04A:
+ case USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081:
if (*rsize >= 113 && rdesc[106] == 0xff && rdesc[107] == 0x7f
&& rdesc[111] == 0xff && rdesc[112] == 0x7f) {
hid_info(hdev, "Fixing up report descriptor\n");
@@ -63,6 +65,8 @@ static const struct hid_device_id holtek_mouse_devices[] = {
USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A067) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT,
USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A04A) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT,
+ USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081) },
{ }
};
MODULE_DEVICE_TABLE(hid, holtek_mouse_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 22134d4..b602b02 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -450,6 +450,7 @@
#define USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD 0xa055
#define USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A067 0xa067
#define USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A04A 0xa04a
+#define USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081 0xa081
#define USB_VENDOR_ID_IMATION 0x0718
#define USB_DEVICE_ID_DISC_STAKKA 0xd000
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: possible conflict between xhci_hcd and a patched usbhid?
From: Sarah Sharp @ 2013-10-01 17:44 UTC (permalink / raw)
To: Cristobal Navarro; +Cc: linux-usb, Xenia Ragiadakou, Alan Stern, linux-input
In-Reply-To: <CALcQQ34PZDQsWr8QDn0NvjpJ0gO9+xjHdcZgSuTtdSsDP=sROw@mail.gmail.com>
On Mon, Sep 30, 2013 at 11:19:56AM -0400, Cristobal Navarro wrote:
> Dear Sarah,
>
> Maybe you can help us. We, Razer Blade laptop users are having a weird
> problem when patching the usbhid module and using the xhci_hcd module at
> the same time.
>
> Razer Blade Laptop users running linux need to fix the polling rate
> interval of the usbhid module, to be 1000Hz in order for the laptop's
> keyboard to work properly (it is a high performance keyboard). That is to
> hardcode a line in drivers/hid/usbhid/hid-core.c to be "interval = 1;",
> around line 1134 of hid-core.c
Can you send me the output of `sudo lsusb -v`? The USB HID driver
should be creating a quirk for this device, rather than having users
hard-code the interval value for all USB HID devices.
> The problem is that if i also include the xhci_hcd module in the kernel,
> then the fix at usbhid no longer works and the keyboard works faultly. So
> at the moment, i have to remove hxci_hcd and loose USB 3.0 support i guess.
Yep, hard coding the interval won't help when the device is under xHCI.
The xHCI driver looks at the endpoint descriptors, not the URB interval,
when it sets up the poll rate. Changing the URB interval will have no
impact on when transfers actually get scheduled. The EHCI driver will
respect the interval in the URB, which is why it works under EHCI.
This has been a known issue for quite some time. What we need is new
API to allow drivers to request a different interval than the one in the
endpoint descriptors. That's not a simple fix, and I don't think it's
going to happen any time soon. Maybe it's something Xenia could look
into?
> Do you know what could be the cause of the problem? how could we fix it?
> Does xhci_hcd module take over the laptop's keyboard instead of usbhid??
>
> many thanks in advance, i appreciatte all the work you have done on USB 3.0.
> Best regards,
>
> Cristobal A. Navarro
Sarah Sharp
^ permalink raw reply
* Fwd: possible conflict between xhci_hcd and a patched usbhid?
From: Cristobal Navarro @ 2013-10-01 18:26 UTC (permalink / raw)
To: linux-input, linux-usb
In-Reply-To: <CALcQQ36zfvSBv9GPE7GfwAmWVtYTf2q5inS5s6YhwghC3aDG0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]
---------- Forwarded message ----------
From: Cristobal Navarro <axischire-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, Oct 1, 2013 at 3:15 PM
Subject: Re: possible conflict between xhci_hcd and a patched usbhid?
To: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Xenia Ragiadakou
<burzalodowa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On Tue, Oct 1, 2013 at 2:44 PM, Sarah Sharp
<sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> On Mon, Sep 30, 2013 at 11:19:56AM -0400, Cristobal Navarro wrote:
> > Dear Sarah,
> >
> > Maybe you can help us. We, Razer Blade laptop users are having a weird
> > problem when patching the usbhid module and using the xhci_hcd module at
> > the same time.
> >
> > Razer Blade Laptop users running linux need to fix the polling rate
> > interval of the usbhid module, to be 1000Hz in order for the laptop's
> > keyboard to work properly (it is a high performance keyboard). That is to
> > hardcode a line in drivers/hid/usbhid/hid-core.c to be "interval = 1;",
> > around line 1134 of hid-core.c
>
> Can you send me the output of `sudo lsusb -v`? The USB HID driver
> should be creating a quirk for this device, rather than having users
> hard-code the interval value for all USB HID devices.
I have attached it as 'lsusb_output.txt'. I think the device where the
keyboard is located is
Bus 001 Device 003: ID 1532:0116 Razer USA, Ltd
Just wanted to add that in addition, the laptop has eight led-keys
(possibly detected as another keyboard), and a trackpad with led
display on the back (in linux works as a trackpad only).
>
>
> > The problem is that if i also include the xhci_hcd module in the kernel,
> > then the fix at usbhid no longer works and the keyboard works faultly. So
> > at the moment, i have to remove hxci_hcd and loose USB 3.0 support i guess.
>
> Yep, hard coding the interval won't help when the device is under xHCI.
> The xHCI driver looks at the endpoint descriptors, not the URB interval,
> when it sets up the poll rate. Changing the URB interval will have no
> impact on when transfers actually get scheduled. The EHCI driver will
> respect the interval in the URB, which is why it works under EHCI.
>
> This has been a known issue for quite some time. What we need is new
> API to allow drivers to request a different interval than the one in the
> endpoint descriptors. That's not a simple fix, and I don't think it's
> going to happen any time soon. Maybe it's something Xenia could look
> into?
I see now. In the worst case, would be great to be able to include
xHCI, at least
hardcoding xHCI source file in an equivalent way as in usbhid,
meanwhile a better fix comes.
If you need more output info just ask me,.
thanks,
Cristobal
>
>
> > Do you know what could be the cause of the problem? how could we fix it?
> > Does xhci_hcd module take over the laptop's keyboard instead of usbhid??
> >
> > many thanks in advance, i appreciatte all the work you have done on USB 3.0.
> > Best regards,
> >
> > Cristobal A. Navarro
>
> Sarah Sharp
[-- Attachment #2: lsusb_output.txt --]
[-- Type: text/plain, Size: 50366 bytes --]
[cristobal@orion ~]$ sudo lsusb -v
Bus 002 Device 005: ID 0cf3:3004 Atheros Communications, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0cf3 Atheros Communications, Inc.
idProduct 0x3004
bcdDevice 0.02
iManufacturer 1 (error)
iProduct 2 (error)
iSerial 3 (error)
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 4 (error)
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Bus 002 Device 003: ID 058f:3823 Alcor Micro Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x058f Alcor Micro Corp.
idProduct 0x3823
bcdDevice 10.16
iManufacturer 1 MCNEX
iProduct 2 SC-20FHL11149M
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 1017
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 4 SC-20FHL11149M
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 79
dwClockFrequency 30.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 28
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {b0d0bb68-a461-834b-90b7-a6215f3c4f70}
bNumControl 24
bNrPins 1
baSourceID( 0) 2
bControlSize 3
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x00040006
Auto-Exposure Mode
Auto-Exposure Priority
Privacy
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000157f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Backlight Compensation
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x 9
None
SECAM - 625/50
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 2
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 7
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
VideoStreaming Interface Descriptor:
bLength 15
bDescriptorType 36
bDescriptorSubtype 1 (INPUT_HEADER)
bNumFormats 2
wTotalLength 827
bEndPointAddress 130
bmInfo 0
bTerminalLink 3
bStillCaptureMethod 2
bTriggerSupport 1
bTriggerUsage 0
bControlSize 1
bmaControls( 0) 11
bmaControls( 1) 11
VideoStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 6 (FORMAT_MJPEG)
bFormatIndex 1
bNumFrameDescriptors 8
bFlags 1
Fixed-size samples: Yes
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 1 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 36864000
dwMaxBitRate 221184000
dwMaxVideoFrameBufferSize 921600
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 160
wHeight 120
dwMinBitRate 2304000
dwMaxBitRate 13824000
dwMaxVideoFrameBufferSize 57600
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 176
wHeight 144
dwMinBitRate 3041280
dwMaxBitRate 18247680
dwMaxVideoFrameBufferSize 76032
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 320
wHeight 240
dwMinBitRate 9216000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 230400
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 5
bmCapabilities 0x00
Still image unsupported
wWidth 352
wHeight 288
dwMinBitRate 12165120
dwMaxBitRate 72990720
dwMaxVideoFrameBufferSize 304128
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 6
bmCapabilities 0x00
Still image unsupported
wWidth 800
wHeight 600
dwMinBitRate 57600000
dwMaxBitRate 345600000
dwMaxVideoFrameBufferSize 1440000
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 110592000
dwMaxBitRate 663552000
dwMaxVideoFrameBufferSize 2764800
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 8
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 248832000
dwMaxBitRate 1492992000
dwMaxVideoFrameBufferSize 6220800
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 3 (STILL_IMAGE_FRAME)
bEndpointAddress 0
bNumImageSizePatterns 1
wWidth( 0) 1920
wHeight( 0) 1080
bNumCompressionPatterns 1
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 2
bNumFrameDescriptors 8
guidFormat {59555932-0000-1000-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 24576000
dwMaxBitRate 147456000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 160
wHeight 120
dwMinBitRate 1536000
dwMaxBitRate 9216000
dwMaxVideoFrameBufferSize 38400
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 176
wHeight 144
dwMinBitRate 2027520
dwMaxBitRate 12165120
dwMaxVideoFrameBufferSize 50688
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 320
wHeight 240
dwMinBitRate 6144000
dwMaxBitRate 36864000
dwMaxVideoFrameBufferSize 153600
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 50
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 5
bmCapabilities 0x00
Still image unsupported
wWidth 352
wHeight 288
dwMinBitRate 8110080
dwMaxBitRate 48660480
dwMaxVideoFrameBufferSize 202752
dwDefaultFrameInterval 333333
bFrameIntervalType 6
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
dwFrameInterval( 2) 500000
dwFrameInterval( 3) 666666
dwFrameInterval( 4) 1000000
dwFrameInterval( 5) 2000000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 6
bmCapabilities 0x00
Still image unsupported
wWidth 800
wHeight 600
dwMinBitRate 30720000
dwMaxBitRate 38400000
dwMaxVideoFrameBufferSize 960000
dwDefaultFrameInterval 2000000
bFrameIntervalType 2
dwFrameInterval( 0) 2000000
dwFrameInterval( 1) 2500000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 7
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 58982400
dwMaxBitRate 73728000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 2000000
bFrameIntervalType 2
dwFrameInterval( 0) 2000000
dwFrameInterval( 1) 2500000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 8
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 132710400
dwMaxBitRate 165888000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 2000000
bFrameIntervalType 2
dwFrameInterval( 0) 2000000
dwFrameInterval( 1) 2500000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0c00 2x 1024 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 4 SC-20FHL11149M
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x8000
bcdDevice 0.04
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 8
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 0 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0503 highspeed power enable connect
Port 7: 0000.0103 power enable connect
Port 8: 0000.0100 power
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.11
iManufacturer 3 Linux 3.11.1-2-RAZER ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 001 Device 003: ID 1532:0116 Razer USA, Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1532 Razer USA, Ltd
idProduct 0x0116
bcdDevice 1.00
iManufacturer 1 Razer
iProduct 2 Razer Blade
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 123
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 75
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 159
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 71
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 240
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x8008
bcdDevice 0.04
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 0 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0503 highspeed power enable connect
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.11
iManufacturer 3 Linux 3.11.1-2-RAZER ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1a.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
[cristobal@orion ~]$
^ permalink raw reply
* New USB core API to change interval and max packet size
From: Sarah Sharp @ 2013-10-01 20:45 UTC (permalink / raw)
To: Xenia Ragiadakou; +Cc: linux-usb, Alan Stern, linux-input, linux-media
In-Reply-To: <524B1BF4.6000305@gmail.com>
On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
> Hi Sarah,
>
> I read the mail on 'possible conflict between xhci_hcd and a patched
> usbhid'.
For reference to others:
http://marc.info/?l=linux-usb&m=138064948726038&w=2
http://marc.info/?l=linux-usb&m=138065201426880&w=2
> I looked in xhci and the problem arises in xhci_queue_intr_tx() when
> if (xhci_interval != ep_interval) {
> ...
> urb->interval = xhci_interval;
> }
>
> right?
Yes. The underlying problem is that the xHCI host sets up the endpoint
contexts during the Configure Endpoint command, using the interval from
the device's endpoint descriptors. It also uses the endpoint descriptor
wMaxPacketSize, which can be wrong as well. If the device driver wants
to use a different urb->interval than is in the endpoint descriptor, the
xHCI driver will simply ignore it.
(I'm Ccing the linux-media list, as I've discussed some of these devices
with broken descriptors before.)
> When you say a new API, what do you mean? New functions in usbcore
> to be used by usb device drivers?
Yes. You would export the function in the USB core, and put a prototype
in a USB include file (probably in include/linux/usb.h). Let's say that
function is called usb_change_ep_bandwidth.
Drivers could call into that function when they needed to change either
the bInterval or wMaxPacketSize of a particular endpoint. This could be
during the driver's probe function, or before switching alternate
interface settings, or even after the alt setting is in place, but
userspace dictates the driver use a different bandwidth.
Drivers should pass usb_change_ep_bandwidth a pointer to the endpoint
they need to change, along with the bInterval and wMaxPacketSize values
they would like the endpoint to have. Those values could be stored as
new values in struct usb_host_endpoint.
usb_change_ep_bandwidth would then call into the xHCI driver to drop the
endpoint, re-add it, and then issue a bandwidth change. The xHCI driver
would have to be changed to look at the new fields in usb_host_endpoint,
and set up the endpoint contexts with the interval and packet size from
those fields, instead of the endpoint descriptor.
We should probably set the new values in usb_host_endpoint to zero after
the driver unbinds from the device. Not sure if they should be reset
after the driver switches interfaces. I would have to see the use cases
in the driver.
> Here, it is needed to change the endpoint descriptors with the new
> value in urb so that xhci takes the correct value?
> I mean the fix should be made in usbcore and xhci shall remain intact?
No, we need to fix both the xHCI driver and the USB core.
> I have time to work on that but i 'm not sure that i understood.
Sure. I would actually suggest you first finish up the patch to issue a
configure endpoint if userspace wants to clear a halt, but the endpoint
isn't actually halted. Did your most current patch work? I can't
remember what the status was.
Sarah Sharp
^ permalink raw reply
* Re: New USB core API to change interval and max packet size
From: Xenia Ragiadakou @ 2013-10-01 21:16 UTC (permalink / raw)
To: Sarah Sharp; +Cc: linux-usb, Alan Stern, linux-input, linux-media
In-Reply-To: <20131001204554.GB15395@xanatos>
On 10/01/2013 11:45 PM, Sarah Sharp wrote:
> On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
>> Hi Sarah,
>>
>> I read the mail on 'possible conflict between xhci_hcd and a patched
>> usbhid'.
> For reference to others:
> http://marc.info/?l=linux-usb&m=138064948726038&w=2
> http://marc.info/?l=linux-usb&m=138065201426880&w=2
>
>> I looked in xhci and the problem arises in xhci_queue_intr_tx() when
>> if (xhci_interval != ep_interval) {
>> ...
>> urb->interval = xhci_interval;
>> }
>>
>> right?
> Yes. The underlying problem is that the xHCI host sets up the endpoint
> contexts during the Configure Endpoint command, using the interval from
> the device's endpoint descriptors. It also uses the endpoint descriptor
> wMaxPacketSize, which can be wrong as well. If the device driver wants
> to use a different urb->interval than is in the endpoint descriptor, the
> xHCI driver will simply ignore it.
>
> (I'm Ccing the linux-media list, as I've discussed some of these devices
> with broken descriptors before.)
>
>> When you say a new API, what do you mean? New functions in usbcore
>> to be used by usb device drivers?
> Yes. You would export the function in the USB core, and put a prototype
> in a USB include file (probably in include/linux/usb.h). Let's say that
> function is called usb_change_ep_bandwidth.
>
> Drivers could call into that function when they needed to change either
> the bInterval or wMaxPacketSize of a particular endpoint. This could be
> during the driver's probe function, or before switching alternate
> interface settings, or even after the alt setting is in place, but
> userspace dictates the driver use a different bandwidth.
>
> Drivers should pass usb_change_ep_bandwidth a pointer to the endpoint
> they need to change, along with the bInterval and wMaxPacketSize values
> they would like the endpoint to have. Those values could be stored as
> new values in struct usb_host_endpoint.
>
> usb_change_ep_bandwidth would then call into the xHCI driver to drop the
> endpoint, re-add it, and then issue a bandwidth change. The xHCI driver
> would have to be changed to look at the new fields in usb_host_endpoint,
> and set up the endpoint contexts with the interval and packet size from
> those fields, instead of the endpoint descriptor.
>
> We should probably set the new values in usb_host_endpoint to zero after
> the driver unbinds from the device. Not sure if they should be reset
> after the driver switches interfaces. I would have to see the use cases
> in the driver.
>
>> Here, it is needed to change the endpoint descriptors with the new
>> value in urb so that xhci takes the correct value?
>> I mean the fix should be made in usbcore and xhci shall remain intact?
> No, we need to fix both the xHCI driver and the USB core.
>
>> I have time to work on that but i 'm not sure that i understood.
> Sure. I would actually suggest you first finish up the patch to issue a
> configure endpoint if userspace wants to clear a halt, but the endpoint
> isn't actually halted. Did your most current patch work? I can't
> remember what the status was.
>
> Sarah Sharp
Thanks for the clarification, I understand better now.
As far as concerns the reset endpoint fix, I am not sure if it works I
have to send an RFC so that it can be further tested but I have a lot of
pending RFCs for xhci on the mailing list so i was waiting for those to
be reviewed before sending new ones. Or it is not necessary to wait and
just send the RFC based on current usb-next tree?
regards,
ksenia
^ permalink raw reply
* Re: [PATCH] add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)
From: Florian Echtler @ 2013-10-02 8:01 UTC (permalink / raw)
To: Henrik Rydberg
Cc: linux-input, benjamin.tissoires, dmitry.torokhov, dh.herrmann
In-Reply-To: <20130918193853.GA2070@polaris.bitmath.org>
[-- Attachment #1: Type: text/plain, Size: 4518 bytes --]
On 18.09.2013 21:38, Henrik Rydberg wrote:
> Hi Florian,
> Thanks for the driver, this is excellent work. Please find some nit-picks inline.
Hello Henrik, thanks for your feedback and sorry for the long silence -
some final questions before the next iteration are below:
>> +/* read 512 bytes from endpoint 0x86 -> get header + blobs */
>> +struct sur40_header {
>> +
>> + uint16_t type; /* always 0x0001 */
>> + uint16_t count; /* count of blobs (if 0: continue prev. packet) */
>> +
>> + uint32_t packet_id;
>> +
>> + uint32_t timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
>> + uint32_t unknown; /* "epoch?" always 02/03 00 00 00 */
>> +};
>
> Since you read these structs directly from the device, it would be
> good to see the endianess explicitly. It probably also means this will
> only work on some architectures... ;-) Also, you may want to use the
> __packed attribute.
Do you mean to add a comment about the endianness, or to use other data
types? If so, which ones? __packed is a good point, will add this.
>> +struct sur40_blob {
>> +
>> + uint16_t blob_id;
>> +
>> + uint8_t action; /* 0x02 = enter/exit, 0x03 = update (?) */
>> + uint8_t unknown; /* always 0x01 or 0x02 (no idea what this is?) */
>> +
>> + uint16_t bb_pos_x; /* upper left corner of bounding box */
>> + uint16_t bb_pos_y;
>> +
>> + uint16_t bb_size_x; /* size of bounding box */
>> + uint16_t bb_size_y;
>> +
>> + uint16_t pos_x; /* finger tip position */
>> + uint16_t pos_y;
>> +
>> + uint16_t ctr_x; /* centroid position */
>> + uint16_t ctr_y;
>> +
>> + uint16_t axis_x; /* somehow related to major/minor axis, mostly: */
>> + uint16_t axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
>> +
>> + float angle; /* orientation in radians relative to x axis */
>
> float is unusual in the kernel - is it actually ieee 754 encoded?
Yes - was also surprised to see this directly from the hardware.
> Same here. Also, you could add a struct like this:
>
> struct sur40_data {
> struct sur40_header header;
> struct sur40_blob blobs[];
> };
>
> which should make conversion easier later on.
Good idea.
>> +
>> +/* read 8 bytes using control message 0xc0,0xb1,0x00,0x00 */
>> +struct sur40_sensors {
>> + uint16_t temp;
>> + uint16_t acc_x;
>> + uint16_t acc_y;
>> + uint16_t acc_z;
>> +};
>
> Hmm, seems to be unused?
Yes, I was planning to add some extra interface (sysfs?) for this later.
I'll remove it for now.
>> +/* polling interval (ms) */
>> +#define POLL_INTERVAL 10
>
> Interesting that 100 Hz is enough here - is it the limit of the
> device, or simply picked out of convenience?
The device itself is running at 60 Hz, so I picked a lower interval to
make sure that new packets are polled as soon as they are ready. The USB
bulk read will block anyway until new data is available, so this could
probably even be lowered to 15 ms.
>> + input_mt_slot(input, slotnum);
>> + input_mt_report_slot_state(input, MT_TOOL_FINGER, 1);
>> + wide = (blob->bb_size_x > blob->bb_size_y);
>> + major = max(blob->bb_size_x, blob->bb_size_y);
>> + minor = min(blob->bb_size_x, blob->bb_size_y);
>> +
>> + input_event(input, EV_ABS, ABS_MT_POSITION_X, blob->pos_x);
>> + input_event(input, EV_ABS, ABS_MT_POSITION_Y, blob->pos_y);
>> + input_event(input, EV_ABS, ABS_MT_TOOL_X, blob->ctr_x);
>> + input_event(input, EV_ABS, ABS_MT_TOOL_Y, blob->ctr_y);
>> + input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
>> + input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
>> + input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
>> +}
>
> You mention there is an angle in the data, but I take it it is not (yet) useful?
Right, this could actually be translated into degrees [0..359] and used
for orientation. Good point.
>> + /* use the bulk-in endpoint tested above */
>> + sur40->bulk_in_size = le16_to_cpu(endpoint->wMaxPacketSize);
>> + sur40->bulk_in_epaddr = endpoint->bEndpointAddress;
>> + sur40->bulk_in_buffer = kmalloc(2 * sur40->bulk_in_size, GFP_KERNEL);
>
> The factor of two looks a bit cryptic? There also seem to be functions
> to extract the packet size nowadays, if one wants to get fancy.
Ah, yes. The factor of two is actually completely unnecessary, the USB
bulk read should just use sur40->bulk_in_size for the request size.
Best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)
From: David Herrmann @ 2013-10-02 9:02 UTC (permalink / raw)
To: Florian Echtler
Cc: Henrik Rydberg, open list:HID CORE LAYER, Benjamin Tissoires,
Dmitry Torokhov
In-Reply-To: <524BD2D8.505@butterbrot.org>
Hi Florian
On Wed, Oct 2, 2013 at 10:01 AM, Florian Echtler <floe@butterbrot.org> wrote:
>>> +struct sur40_blob {
>>> +
>>> + uint16_t blob_id;
>>> +
>>> + uint8_t action; /* 0x02 = enter/exit, 0x03 = update (?) */
>>> + uint8_t unknown; /* always 0x01 or 0x02 (no idea what this is?) */
>>> +
>>> + uint16_t bb_pos_x; /* upper left corner of bounding box */
>>> + uint16_t bb_pos_y;
>>> +
>>> + uint16_t bb_size_x; /* size of bounding box */
>>> + uint16_t bb_size_y;
>>> +
>>> + uint16_t pos_x; /* finger tip position */
>>> + uint16_t pos_y;
>>> +
>>> + uint16_t ctr_x; /* centroid position */
>>> + uint16_t ctr_y;
>>> +
>>> + uint16_t axis_x; /* somehow related to major/minor axis, mostly: */
>>> + uint16_t axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
>>> +
>>> + float angle; /* orientation in radians relative to x axis */
>>
>> float is unusual in the kernel - is it actually ieee 754 encoded?
>
> Yes - was also surprised to see this directly from the hardware.
How about renaming this to "__angle" or "angle_dont_use" or something
like that. Thing is, we don't restore FP registers in the kernel so if
there's a float somewhere around, we should never access it as float
(who knows what the compiler generates..). There might be FP macros to
save/restore the registers, but I haven't seen them used.
Or maybe even replace it by "u32 angle;". That should always be safe.
Once you make use of this field, you can reconsider whether it's worth
doing FP in the kernel. But as long as it's unused, I'd vote for
avoiding "float" entirely.
Thanks
David
^ permalink raw reply
* Re: [PATCH] update my generaltouch driver for linux by luosong
From: Benjamin Tissoires @ 2013-10-02 9:15 UTC (permalink / raw)
To: android; +Cc: jkosina, linux-input, Henrik Rydberg
In-Reply-To: <2013092515142828117311@generaltouch.com>
Hi Luosong,
ok, your mailer still sends emails as HTML, and it also mangles the
tabs, which is not good for the LKML.
The commit message is a little bit fuzzy and does not follow the kernel
rules. I'll send a followup patch correctly formatted so that we can all
switch to something else.
Cheers,
Benjamin
On 25/09/13 09:14, Lamson_Luo wrote:
> Dear,Sir
>
> OK,I have modified some problems for this patch as follows:
> (1) I have used my real name ,my name is Luosong, my email is
> android@generaltouch.com <mailto:android@generaltouch.com>
> (2) I have sorted
> alphabetically the PID you are adding both in hid-multitouch,c and hid-ids.h(0003
> to e100)
> (3) I have tested them in our products.
>
> In addition, I have added the patch into the attachment
>
>
> commit ef879474d31fbf671f1eadda1b618a606c28e680 Mon Sep 17 00:00:00 2001
> From: Luosong <android@generaltouch.com>
> Date: Wed, 25 Sep 2013 06:22:48 +0800
> Subject: [PATCH] "0101,e100,0102,0106,010a", these ID are our GeneralTouch's
> new products change to "MT_QUIRK_SLOT_IS_CONTACTID",doing
> this is for correcting a bug for our GeneralTouch'products
>
> Signed-off-by: Luosong <android@generaltouch.com>
>
> ---
> drivers/hid/hid-ids.h | 5 +++++
> drivers/hid/hid-multitouch.c | 19 +++++++++++++++++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index e60e8d5..9a91dee 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -332,6 +332,11 @@
> #define USB_VENDOR_ID_GENERAL_TOUCH 0x0dfc
> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN7_TWOFINGERS 0x0003
> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS 0x0100
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>
> #define USB_VENDOR_ID_GLAB 0x06c2
> #define USB_DEVICE_ID_4_PHIDGETSERVO_30 0x0038
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 5e5fe1b..cb3250c 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -250,12 +250,12 @@ static struct mt_class mt_classes[] = {
> { .name = MT_CLS_GENERALTOUCH_TWOFINGERS,
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
> MT_QUIRK_VALID_IS_INRANGE |
> - MT_QUIRK_SLOT_IS_CONTACTNUMBER,
> + MT_QUIRK_SLOT_IS_CONTACTID,
> .maxcontacts = 2
> },
> { .name = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
> + MT_QUIRK_SLOT_IS_CONTACTID
> },
>
> { .name = MT_CLS_FLATFROG,
> @@ -1173,6 +1173,21 @@ static const struct hid_device_id mt_devices[] = {
> { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS) },
> + { .driver_data = MT_CLS_GENERALTOUCH_TWOFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100) },
>
> /* Gametel game controller */
> { .driver_data = MT_CLS_NSMU,
> --
> 1.7.9.5
>
> **********************************************************************************
> **********************************************************************************************
>
> Hi,
>
> On 17/09/13 04:15, Lamson_Luo wrote:
>> Hi,Sir
>> I am sorry to trouble you .
>>
>> I want to ask you something about adding our GeneralTouch's patch
>>
>> is it OK?
>
> well, it is nearly ok:
> - I have nothing against the patch, regarding the fact that you are
> working for GeneralTouch and that I hope that you have tested it against
> the new devices and the older ones.
> - small nitpick in the patch anyway, could you please just sort
> alphabetically the PID you are adding both in hid-multitouch,c and hid-ids.h
> - your mail client continue to try to send your messages as HTML, which
> are rejected by linux-input@vger...
> - you should inline the patch in the mail. The simplest way to do that
> is to use the commands "git format-patch" then "git send-email" which
> will do all the tedious work for you (or nearly)
> - the "from" field and your Signed-off-by is not compliant with the
> kernel rules:
> see "12) Sign your work" in the file Documentation/SubmittingPatches in
> the kernel tree (Jiri already pointed this link) The important part is:
> "using your real name (sorry, no pseudonyms or anonymous contributions.)"
>
>> or what should we do ?
>
> follow the rule number 10) in the previously mentioned document:
> "Don't get discouraged. Re-submit."
>
>>
>> which linux version is it updated in ?
>
> Given that Jiri is currently attending LPC in New Orleans, don't expect
> a very fast answer from him currently. Then, once it will land in his
> tree, it will be scheduled for the next Linux release (3.12 or 3.13),
> and Jiri may also submit it to stable if there are no conflicts (i.e. in
> this case 3.10 and 3.11 I would say).
>
> Cheers,
> Benjamin
>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Please feel free to contact me if you have any question.
>> Thanks & Best Regards
>>
>> Email: android@generaltouch.com <mailto:android@generaltouch.com>
>> R&D Department
>> GeneralTouch Technology Co., Ltd.
>>
>> *发件人：* Lamson_Luo <mailto:android@generaltouch.com>
>> *发送时间：* 2013-09-10 11:20
>> *收件人：* jkosina <mailto:jkosina@suse.cz>
>> *抄送：* linux-input <mailto:linux-input@vger.kernel.org>; Henrik
>> Rydberg <mailto:rydberg@euromail.se>; Benjamin Tissoires
>> <mailto:benjamin.tissoires@redhat.com>
>> *主
> 题：* Re: Re: [PATCH] update my generaltouch driver for linux by luosong
>> Dear,Jiri Kosina
>> thanks for your reply
>>
>> for your message, my reply is as follows:
>>
>> 1)
>> On Mon, 9 Sep 2013, android wrote:
>>
>>> I am a software engineer from GeneralTouch Technology Co., Ltd.
>>>
>>> I want to add some driver patches to the linux kernel .
>>>
>>> I do these jobs in hid-ids.h and hid-multitouch.c
>>
>> Adding Henrik and Benjamon to CC for the hid-multitouch driver.
>>
>> [RE]:
>> yes,I added them.
>> but when I tried to send this mail to
>> linux-input(linux-input@vger.kernel.org ) ,I failed to do it.
>> the reference info is :
>> # host vger.kernel.org[209.132.180.67] said: 550 5.7.1 Content-Policy
>> reject msg: The message contains HTML, therefore we consider it SPAM.
>> Send pure TEXT/PLAIN if you are not a spammer. BF:_; S1750878Ab3IIIli
>> (in reply to end of DATA command) _
>>
>> 2)
>>
>>> The main changes in hid driver are like those:
>>> (1)add our new products into kernel driver
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
>>> (2) correct previous bug
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
>>> + MT_QUIRK_SLOT_IS_CONTACTID
>>
>> This needs explanation / clarification in the changelog.
>>
>>
>> [RE]:
>>
>> I will give you the reference changelog:
>>
>> commit 94e68a8c72e2dc300a08a751cd52d9a97cbb43ac
>> Author: luosong <android@generaltouch.com>
>> Date: Tue Sep 10 02:04:46 2013 +0800
>>
>> hid-for-generaltouch
>>
>> "0101,e100,0102,0106,010a", these ID are our GeneralTouch's new products
>> change to "MT_QUIRK_SLOT_IS_CONTACTID",doing this is for correcting a bug for our GeneralTouch'products
>> Signed-off-by:luosong android@generaltouch.com
>> <mailto:android@generaltouch.com>
>>
>>
>>
>>
>> 3)
>>> the content of patch is shown below:
>>>
>>> From 5db217392e661695058606c7919be7fa6509f1e4 Mon Sep 17 00:00:00 2001
>>> From: luosong android@generaltouch.com
>>
>> This doesn't look like a RFC-compliant from, I think.
>>
>> [RE]:
>> I got the source by git tool ,I built a branch named
>> hid-for-generaltouch ,and I also configured my username and mail.
>>
>>
>>
>> 4)
>>> Date: Mon, 9 Sep 2013 02:30:10 +0800
>>> Subject: [PATCH] update my generaltouch driver for linux by luosong
>>
>> Please insert changelog (description of the changes) and Signed-off-by:
>> line here, as documented in Documentation/SubmittingPatches
>>
>>
>> [RE]:
>> "0101,e100,0102,0106,010a", these ID are our GeneralTouch's new products
>> change to "MT_QUIRK_SLOT_IS_CONTACTID",doing this is for correcting a bug for our GeneralTouch'products
>>
>> 5)
>>> ---
>>> drivers/hid/hid-ids.h | 5 +++++
>>> drivers/hid/hid-multitouch.c | 19 +++++++++++++++++--
>>> 2 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>>> index ffe4c7a..ca78f09 100644
>>> --- a/drivers/hid/hid-ids.h
>>> +++ b/drivers/hid/hid-ids.h
>>> @@ -332,6 +332,11 @@
>>> #define USB_VENDOR_ID_GENERAL_TOUCH 0x0dfc
>>> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN7_TWOFINGERS 0x0003
>>> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS 0x0100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
>>>
>>> #define USB_VENDOR_ID_GLAB 0x06c2
>>> #define USB_DEVICE_ID_4_PHIDGETSERVO_30 0x0038
>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>> index cb0e361..9558dde 100644
>>> --- a/drivers/hid/hid-multitouch.c
>>> +++ b/drivers/hid/hid-multitouch.c
>>> @@ -244,12 +244,12 @@ static struct mt_class mt_classes[] = {
>>> { .name = MT_CLS_GENERALTOUCH_TWOFINGERS,
>>> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
>>> MT_QUIRK_VALID_IS_INRANGE |
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER,
>>> + MT_QUIRK_SLOT_IS_CONTACTID,
>>> .maxcontacts = 2
>>> },
>>> { .name = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
>>> + MT_QUIRK_SLOT_IS_CONTACTID
>>> },
>>>
>>> { .name = MT_CLS_FLATFROG,
>>> @@ -1191,6 +1191,21 @@ static const struct hid_device_id mt_devices[] = {
>>> { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_TWOFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A) },
>>
>> Your mail client seems to be whitespace-corrupting patches (it ate the
>> tabs at least).
>>
>> Could you please fix all the above and resubmit?
>>
>> [RE]:
>> I will send some attachments to you
>>
>>
>> is it OK? if it is not right,could you help me to modify it?
>>
>>
>>
>>
>>
>>
>> *From:* Jiri Kosina <mailto:jkosina@suse.cz>
>> *Date:* 2013-09-09 21:04
>> *To:* android <mailto:android@generaltouch.com>
>> *CC:* linux-input <mailto:linux-input@vger.kernel.org>; Henrik Rydberg
>> <mailto:rydberg@euromail.se>; Benjamin Tissoires
>> <mailto:benjamin.tissoires@redhat.com>
>> *Subject:* Re: [PATCH] update my generaltouch driver for linux by luosong
>> On Mon, 9 Sep 2013, android wrote:
>>
>>> I am a software engineer from GeneralTouch Technology Co., Ltd.
>>>
>>> I want to add some driver patches to the linux kernel .
>>>
>>> I do these jobs in hid-ids.h and hid-multitouch.c
>>
>> Adding Henrik and Benjamon to CC for the hid-multitouch driver.
>>
>>> The main changes in hid driver are like those:
>>> (1)add our new products into kernel driver
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
>>> (2) correct previous bug
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
>>> + MT_QUIRK_SLOT_IS_CONTACTID
>>
>> This needs explanation / clarification in the changelog.
>>
>>> the content of patch is shown below:
>>>
>>> From 5db217392e661695058606c7919be7fa6509f1e4 Mon Sep 17 00:00:00 2001
>>> From: luosong android@generaltouch.com
>>
>> This doesn't look like a RFC-compliant from, I think.
>>
>>> Date: Mon, 9 Sep 2013 02:30:10 +0800
>>> Subject: [PATCH] update my generaltouch driver for linux by luosong
>>
>> Please insert changelog (description of the changes) and Signed-off-by:
>> line here, as documented in Documentation/SubmittingPatches
>>
>>> ---
>>> drivers/hid/hid-ids.h | 5 +++++
>>> drivers/hid/hid-multitouch.c | 19 +++++++++++++++++--
>>> 2 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>>> index ffe4c7a..ca78f09 100644
>>> --- a/drivers/hid/hid-ids.h
>>> +++ b/drivers/hid/hid-ids.h
>>> @@ -332,6 +332,11 @@
>>> #define USB_VENDOR_ID_GENERAL_TOUCH 0x0dfc
>>> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN7_TWOFINGERS 0x0003
>>> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS 0x0100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
>>> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
>>>
>>> #define USB_VENDOR_ID_GLAB 0x06c2
>>> #define USB_DEVICE_ID_4_PHIDGETSERVO_30 0x0038
>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>> index cb0e361..9558dde 100644
>>> --- a/drivers/hid/hid-multitouch.c
>>> +++ b/drivers/hid/hid-multitouch.c
>>> @@ -244,12 +244,12 @@ static struct mt_class mt_classes[] = {
>>> { .name = MT_CLS_GENERALTOUCH_TWOFINGERS,
>>> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
>>> MT_QUIRK_VALID_IS_INRANGE |
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER,
>>> + MT_QUIRK_SLOT_IS_CONTACTID,
>>> .maxcontacts = 2
>>> },
>>> { .name = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
>>> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
>>> + MT_QUIRK_SLOT_IS_CONTACTID
>>> },
>>>
>>> { .name = MT_CLS_FLATFROG,
>>> @@ -1191,6 +1191,21 @@ static const struct hid_device_id mt_devices[] = {
>>> { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_TWOFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106) },
>>> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
>>> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
>>> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A) },
>>
>> Your mail client seems to be whitespace-corrupting patches (it ate the
>> tabs at least).
>>
>> Could you please fix all the above and resubmit?
>>
>> Thanks a lot,
>>
>> --
>> Jiri Kosina
>> SUSE Labs
>>
>>
>
>
>
--
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
* [PATCH] HID: multitouch: Fix GeneralTouch products and add more PIDs
From: Benjamin Tissoires @ 2013-10-02 9:20 UTC (permalink / raw)
To: Benjamin Tissoires, Henrik Rydberg, Jiri Kosina, linux-input,
linux-kernel
Cc: Luosong, Benjamin Tissoires
From: Luosong <android@generaltouch.com>
GeneralTouch products should use the quirk SLOT_IS_CONTACTID
instead of SLOT_IS_CONTACTNUMBER.
Adding PIDs 0101,e100,0102,0106,010a from the new products.
Tested on new and older products by GeneralTouch engineers.
Signed-off-by: Luosong <android@generaltouch.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi Luosong,
I took the liberty to rewrite the commit message for it to be
more compliant with the kernel rules:
- there should be a one line title commit message first,
- and the rest should detail the patch, tell how it was tested, etc...
If you could just give our ack on this one, Jiri would be able to take it
through his tree.
Cheers,
Benjamin
drivers/hid/hid-ids.h | 5 +++++
drivers/hid/hid-multitouch.c | 19 +++++++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e60e8d5..9a91dee 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -332,6 +332,11 @@
#define USB_VENDOR_ID_GENERAL_TOUCH 0x0dfc
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN7_TWOFINGERS 0x0003
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS 0x0100
+#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
+#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
+#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
+#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
+#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
#define USB_VENDOR_ID_GLAB 0x06c2
#define USB_DEVICE_ID_4_PHIDGETSERVO_30 0x0038
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 5e5fe1b..cb3250c 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -250,12 +250,12 @@ static struct mt_class mt_classes[] = {
{ .name = MT_CLS_GENERALTOUCH_TWOFINGERS,
.quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
MT_QUIRK_VALID_IS_INRANGE |
- MT_QUIRK_SLOT_IS_CONTACTNUMBER,
+ MT_QUIRK_SLOT_IS_CONTACTID,
.maxcontacts = 2
},
{ .name = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
.quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
- MT_QUIRK_SLOT_IS_CONTACTNUMBER
+ MT_QUIRK_SLOT_IS_CONTACTID
},
{ .name = MT_CLS_FLATFROG,
@@ -1173,6 +1173,21 @@ static const struct hid_device_id mt_devices[] = {
{ .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS) },
+ { .driver_data = MT_CLS_GENERALTOUCH_TWOFINGERS,
+ MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
+ USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101) },
+ { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
+ MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
+ USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102) },
+ { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
+ MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
+ USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106) },
+ { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
+ MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
+ USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A) },
+ { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
+ MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
+ USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100) },
/* Gametel game controller */
{ .driver_data = MT_CLS_NSMU,
--
1.8.3.1
^ permalink raw reply related
* [PATCH] HID: wiimote: fix FF deadlock
From: David Herrmann @ 2013-10-02 11:47 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, David Herrmann, stable
The input core has an internal spinlock that is acquired during event
injection via input_event() and friends but also held during FF callbacks.
That means, there is no way to share a lock between event-injection and FF
handling. Unfortunately, this is what is required for wiimote state
tracking and what we do with state.lock and input->lock.
This deadlock can be triggered when using continuous data reporting and FF
on a wiimote device at the same time. I takes me at least 30m of
stress-testing to trigger it but users reported considerably shorter
times (http://bpaste.net/show/132504/) when using some gaming-console
emulators.
The real problem is that we have two copies of internal state, one in the
wiimote objects and the other in the input device. As the input-lock is
not supposed to be accessed from outside of input-core, we have no other
chance than offloading FF handling into a worker. This actually works
pretty nice and also allows to implictly merge fast rumble changes into a
single request.
Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
responsiveness. Initial tests were fine so lets fix the race first and if
it turns out to be too slow we can always handle FF out-of-band and skip
the queue-worker.
Cc: <stable@vger.kernel.org> # 3.11+
Reported-by: Thomas Schneider
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
drivers/hid/hid-wiimote-modules.c | 40 ++++++++++++++++++++++++++++-----------
drivers/hid/hid-wiimote.h | 4 +++-
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/hid-wiimote-modules.c b/drivers/hid/hid-wiimote-modules.c
index 2e7d644..71adf9e 100644
--- a/drivers/hid/hid-wiimote-modules.c
+++ b/drivers/hid/hid-wiimote-modules.c
@@ -119,12 +119,22 @@ static const struct wiimod_ops wiimod_keys = {
* the rumble motor, this flag shouldn't be set.
*/
+/* used by wiimod_rumble and wiipro_rumble */
+static void wiimod_rumble_worker(struct work_struct *work)
+{
+ struct wiimote_data *wdata = container_of(work, struct wiimote_data,
+ rumble_worker);
+
+ spin_lock_irq(&wdata->state.lock);
+ wiiproto_req_rumble(wdata, wdata->state.cache_rumble);
+ spin_unlock_irq(&wdata->state.lock);
+}
+
static int wiimod_rumble_play(struct input_dev *dev, void *data,
struct ff_effect *eff)
{
struct wiimote_data *wdata = input_get_drvdata(dev);
__u8 value;
- unsigned long flags;
/*
* The wiimote supports only a single rumble motor so if any magnitude
@@ -137,9 +147,10 @@ static int wiimod_rumble_play(struct input_dev *dev, void *data,
else
value = 0;
- spin_lock_irqsave(&wdata->state.lock, flags);
- wiiproto_req_rumble(wdata, value);
- spin_unlock_irqrestore(&wdata->state.lock, flags);
+ /* Locking state.lock here might deadlock with input_event() calls.
+ * schedule_work acts as barrier. Merging multiple changes is fine. */
+ wdata->state.cache_rumble = value;
+ schedule_work(&wdata->rumble_worker);
return 0;
}
@@ -147,6 +158,8 @@ static int wiimod_rumble_play(struct input_dev *dev, void *data,
static int wiimod_rumble_probe(const struct wiimod_ops *ops,
struct wiimote_data *wdata)
{
+ INIT_WORK(&wdata->rumble_worker, wiimod_rumble_worker);
+
set_bit(FF_RUMBLE, wdata->input->ffbit);
if (input_ff_create_memless(wdata->input, NULL, wiimod_rumble_play))
return -ENOMEM;
@@ -159,6 +172,8 @@ static void wiimod_rumble_remove(const struct wiimod_ops *ops,
{
unsigned long flags;
+ cancel_work_sync(&wdata->rumble_worker);
+
spin_lock_irqsave(&wdata->state.lock, flags);
wiiproto_req_rumble(wdata, 0);
spin_unlock_irqrestore(&wdata->state.lock, flags);
@@ -1731,7 +1746,6 @@ static int wiimod_pro_play(struct input_dev *dev, void *data,
{
struct wiimote_data *wdata = input_get_drvdata(dev);
__u8 value;
- unsigned long flags;
/*
* The wiimote supports only a single rumble motor so if any magnitude
@@ -1744,9 +1758,10 @@ static int wiimod_pro_play(struct input_dev *dev, void *data,
else
value = 0;
- spin_lock_irqsave(&wdata->state.lock, flags);
- wiiproto_req_rumble(wdata, value);
- spin_unlock_irqrestore(&wdata->state.lock, flags);
+ /* Locking state.lock here might deadlock with input_event() calls.
+ * schedule_work acts as barrier. Merging multiple changes is fine. */
+ wdata->state.cache_rumble = value;
+ schedule_work(&wdata->rumble_worker);
return 0;
}
@@ -1756,6 +1771,8 @@ static int wiimod_pro_probe(const struct wiimod_ops *ops,
{
int ret, i;
+ INIT_WORK(&wdata->rumble_worker, wiimod_rumble_worker);
+
wdata->extension.input = input_allocate_device();
if (!wdata->extension.input)
return -ENOMEM;
@@ -1817,12 +1834,13 @@ static void wiimod_pro_remove(const struct wiimod_ops *ops,
if (!wdata->extension.input)
return;
+ input_unregister_device(wdata->extension.input);
+ wdata->extension.input = NULL;
+ cancel_work_sync(&wdata->rumble_worker);
+
spin_lock_irqsave(&wdata->state.lock, flags);
wiiproto_req_rumble(wdata, 0);
spin_unlock_irqrestore(&wdata->state.lock, flags);
-
- input_unregister_device(wdata->extension.input);
- wdata->extension.input = NULL;
}
static const struct wiimod_ops wiimod_pro = {
diff --git a/drivers/hid/hid-wiimote.h b/drivers/hid/hid-wiimote.h
index f1474f3..75db0c4 100644
--- a/drivers/hid/hid-wiimote.h
+++ b/drivers/hid/hid-wiimote.h
@@ -133,13 +133,15 @@ struct wiimote_state {
__u8 *cmd_read_buf;
__u8 cmd_read_size;
- /* calibration data */
+ /* calibration/cache data */
__u16 calib_bboard[4][3];
+ __u8 cache_rumble;
};
struct wiimote_data {
struct hid_device *hdev;
struct input_dev *input;
+ struct work_struct rumble_worker;
struct led_classdev *leds[4];
struct input_dev *accel;
struct input_dev *ir;
--
1.8.4
^ permalink raw reply related
* Re: New USB core API to change interval and max packet size
From: Mauro Carvalho Chehab @ 2013-10-02 12:33 UTC (permalink / raw)
To: Sarah Sharp
Cc: Xenia Ragiadakou, linux-usb, Alan Stern, linux-input, linux-media
In-Reply-To: <20131001204554.GB15395@xanatos>
Hi Sarah,
Em Tue, 1 Oct 2013 13:45:54 -0700
Sarah Sharp <sarah.a.sharp@linux.intel.com> escreveu:
> On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
> > Hi Sarah,
> >
> > I read the mail on 'possible conflict between xhci_hcd and a patched
> > usbhid'.
>
> For reference to others:
> http://marc.info/?l=linux-usb&m=138064948726038&w=2
> http://marc.info/?l=linux-usb&m=138065201426880&w=2
>
> > I looked in xhci and the problem arises in xhci_queue_intr_tx() when
> > if (xhci_interval != ep_interval) {
> > ...
> > urb->interval = xhci_interval;
> > }
> >
> > right?
>
> Yes. The underlying problem is that the xHCI host sets up the endpoint
> contexts during the Configure Endpoint command, using the interval from
> the device's endpoint descriptors. It also uses the endpoint descriptor
> wMaxPacketSize, which can be wrong as well. If the device driver wants
> to use a different urb->interval than is in the endpoint descriptor, the
> xHCI driver will simply ignore it.
>
> (I'm Ccing the linux-media list, as I've discussed some of these devices
> with broken descriptors before.)
>
> > When you say a new API, what do you mean? New functions in usbcore
> > to be used by usb device drivers?
>
> Yes. You would export the function in the USB core, and put a prototype
> in a USB include file (probably in include/linux/usb.h). Let's say that
> function is called usb_change_ep_bandwidth.
>
> Drivers could call into that function when they needed to change either
> the bInterval or wMaxPacketSize of a particular endpoint. This could be
> during the driver's probe function, or before switching alternate
> interface settings, or even after the alt setting is in place, but
> userspace dictates the driver use a different bandwidth.
>
> Drivers should pass usb_change_ep_bandwidth a pointer to the endpoint
> they need to change, along with the bInterval and wMaxPacketSize values
> they would like the endpoint to have. Those values could be stored as
> new values in struct usb_host_endpoint.
Let me see if I understand the changes at the media drivers. So, please
correct me if I got it wrong.
I'm yet to get any USB 3.0 media device, although it is common to connect
an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
So, for example, on this device:
Bus 003 Device 002: ID 2040:6600 Hauppauge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2040 Hauppauge
idProduct 0x6600
bcdDevice 0.69
iManufacturer 16
iProduct 32 HVR900H
iSerial 64 4031932745
...
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 1
...
connected via this BUS device:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.11
iManufacturer 3 Linux 3.11.2-201.fc19.x86_64 xhci_hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:14.0
In such situation, and assuming that the USB tables are correct, there's
nothing that needs to be done there, as bInterval/wMaxPacketSize are
correct for USB 2.0.
So, there's no need to call usb_change_ep_bandwidth().
If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
or wMaxPacketSize were improperly filled.
Right?
--
Cheers,
Mauro
^ permalink raw reply
* Re: New USB core API to change interval and max packet size
From: Alan Stern @ 2013-10-02 14:22 UTC (permalink / raw)
To: Sarah Sharp
Cc: Xenia Ragiadakou, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131001204554.GB15395@xanatos>
On Tue, 1 Oct 2013, Sarah Sharp wrote:
> > When you say a new API, what do you mean? New functions in usbcore
> > to be used by usb device drivers?
>
> Yes. You would export the function in the USB core, and put a prototype
> in a USB include file (probably in include/linux/usb.h). Let's say that
> function is called usb_change_ep_bandwidth.
>
> Drivers could call into that function when they needed to change either
> the bInterval or wMaxPacketSize of a particular endpoint. This could be
> during the driver's probe function, or before switching alternate
> interface settings, or even after the alt setting is in place, but
> userspace dictates the driver use a different bandwidth.
>
> Drivers should pass usb_change_ep_bandwidth a pointer to the endpoint
> they need to change, along with the bInterval and wMaxPacketSize values
> they would like the endpoint to have. Those values could be stored as
> new values in struct usb_host_endpoint.
>
> usb_change_ep_bandwidth would then call into the xHCI driver to drop the
> endpoint, re-add it, and then issue a bandwidth change. The xHCI driver
> would have to be changed to look at the new fields in usb_host_endpoint,
> and set up the endpoint contexts with the interval and packet size from
> those fields, instead of the endpoint descriptor.
>
> We should probably set the new values in usb_host_endpoint to zero after
> the driver unbinds from the device. Not sure if they should be reset
> after the driver switches interfaces. I would have to see the use cases
> in the driver.
We should consider this before rushing into a new API.
In particular, do we want to go around changing single endpoints, one
at a time? Or do we want to change all the endpoints in an interface
at once?
Given that a change to one endpoint may require the entire schedule to
be recomputed, it seems to make more sense to do all of them at once.
For example, drivers could call a routine to set the desired endpoint
parameters, and then the new parameters could take effect when the
driver calls usb_set_interface().
In any case, the question about what to do when the interface setting
gets switched never really arises. Each usb_host_endpoint structure is
referenced from only one altsetting. If the driver wants the new
parameters applied to an endpoint in several altsettings, it will have
to change each altsetting separately.
Alan Stern
--
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: [PATCH] HID: multitouch: Fix GeneralTouch products and add more PIDs
From: Jiri Kosina @ 2013-10-02 14:55 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, Henrik Rydberg, linux-input, linux-kernel,
Luosong
In-Reply-To: <1380705600-11055-1-git-send-email-benjamin.tissoires@redhat.com>
On Wed, 2 Oct 2013, Benjamin Tissoires wrote:
> From: Luosong <android@generaltouch.com>
>
> GeneralTouch products should use the quirk SLOT_IS_CONTACTID
> instead of SLOT_IS_CONTACTNUMBER.
>
> Adding PIDs 0101,e100,0102,0106,010a from the new products.
>
> Tested on new and older products by GeneralTouch engineers.
>
> Signed-off-by: Luosong <android@generaltouch.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Hi Luosong,
>
> I took the liberty to rewrite the commit message for it to be
> more compliant with the kernel rules:
> - there should be a one line title commit message first,
> - and the rest should detail the patch, tell how it was tested, etc...
>
> If you could just give our ack on this one, Jiri would be able to take it
> through his tree.
Thanks Benjamin.
Luosong, the patch as sent by Benjamin is properly formatted and contains
proper changelog. Please make sure that you fix your patch submission
workflow for your next submissions.
Luosong, please let me know that you are find with applying the patch as
Benjamin sent it (with attribution to you and your signoff), and I'll
proceed.
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-ids.h | 5 +++++
> drivers/hid/hid-multitouch.c | 19 +++++++++++++++++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index e60e8d5..9a91dee 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -332,6 +332,11 @@
> #define USB_VENDOR_ID_GENERAL_TOUCH 0x0dfc
> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN7_TWOFINGERS 0x0003
> #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS 0x0100
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101 0x0101
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102 0x0102
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106 0x0106
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
> +#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
>
> #define USB_VENDOR_ID_GLAB 0x06c2
> #define USB_DEVICE_ID_4_PHIDGETSERVO_30 0x0038
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 5e5fe1b..cb3250c 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -250,12 +250,12 @@ static struct mt_class mt_classes[] = {
> { .name = MT_CLS_GENERALTOUCH_TWOFINGERS,
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
> MT_QUIRK_VALID_IS_INRANGE |
> - MT_QUIRK_SLOT_IS_CONTACTNUMBER,
> + MT_QUIRK_SLOT_IS_CONTACTID,
> .maxcontacts = 2
> },
> { .name = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
> - MT_QUIRK_SLOT_IS_CONTACTNUMBER
> + MT_QUIRK_SLOT_IS_CONTACTID
> },
>
> { .name = MT_CLS_FLATFROG,
> @@ -1173,6 +1173,21 @@ static const struct hid_device_id mt_devices[] = {
> { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PWT_TENFINGERS) },
> + { .driver_data = MT_CLS_GENERALTOUCH_TWOFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0101) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0102) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_0106) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A) },
> + { .driver_data = MT_CLS_GENERALTOUCH_PWT_TENFINGERS,
> + MT_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH,
> + USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100) },
>
> /* Gametel game controller */
> { .driver_data = MT_CLS_NSMU,
> --
> 1.8.3.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: New USB core API to change interval and max packet size
From: Alan Stern @ 2013-10-02 15:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sarah Sharp, Xenia Ragiadakou, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131002093354.507cd24d-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
> Let me see if I understand the changes at the media drivers. So, please
> correct me if I got it wrong.
>
> I'm yet to get any USB 3.0 media device, although it is common to connect
> an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
>
> So, for example, on this device:
> ...
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0004 1x 4 bytes
> bInterval 1
> ...
>
> connected via this BUS device:
...
> In such situation, and assuming that the USB tables are correct, there's
> nothing that needs to be done there, as bInterval/wMaxPacketSize are
> correct for USB 2.0.
>
> So, there's no need to call usb_change_ep_bandwidth().
That's right.
> If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> or wMaxPacketSize were improperly filled.
>
> Right?
Or if the values are correct, but the driver wants to use something
different for its own reasons (for example, to get lower latency or
because it knows that it will never use packets as large as the
descriptor allows). Right.
Alan Stern
--
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: [PATCH] HID: Added Holtek USB ID 04d9:a081 SHARKOON DarkGlider Gaming mouse
From: Jiri Kosina @ 2013-10-02 15:04 UTC (permalink / raw)
To: Anders F. U. Kiær; +Cc: linux-input, linux-kernel
In-Reply-To: <1380648125-5735-1-git-send-email-ablacksheep@gmail.com>
On Tue, 1 Oct 2013, Anders F. U. Kiær wrote:
> Target: 3.11.2
> Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON
> DarkGlider Gaming mouse to use the same corrections of the report
> descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES
> at the same offsets in the reported descriptor.
> Tested on the hardware.
>
> Signed-off-by: Anders F. U. Kiær <ablacksheep@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
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: New USB core API to change interval and max packet size
From: Mauro Carvalho Chehab @ 2013-10-02 16:15 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Xenia Ragiadakou, linux-usb, linux-input,
linux-media
In-Reply-To: <Pine.LNX.4.44L0.1310021057250.1293-100000@iolanthe.rowland.org>
Em Wed, 02 Oct 2013 11:00:13 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> escreveu:
> On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
>
> > Let me see if I understand the changes at the media drivers. So, please
> > correct me if I got it wrong.
> >
> > I'm yet to get any USB 3.0 media device, although it is common to connect
> > an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
> >
> > So, for example, on this device:
>
> > ...
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 3
> > Transfer Type Interrupt
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0004 1x 4 bytes
> > bInterval 1
> > ...
> >
> > connected via this BUS device:
>
> ...
>
> > In such situation, and assuming that the USB tables are correct, there's
> > nothing that needs to be done there, as bInterval/wMaxPacketSize are
> > correct for USB 2.0.
> >
> > So, there's no need to call usb_change_ep_bandwidth().
>
> That's right.
>
> > If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> > or wMaxPacketSize were improperly filled.
> >
> > Right?
>
> Or if the values are correct, but the driver wants to use something
> different for its own reasons (for example, to get lower latency or
> because it knows that it will never use packets as large as the
> descriptor allows). Right.
Ok, so, in this case, usb_change_ep_bandwidth() could be called
just before usb_alloc_urb(), in order to make it to use the packet
size that would be expected for that kind of ISOC traffic that
userspace indirectly selected, by adjusting the streaming
video resolution selected, right?
Regards,
Mauro
^ 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