* [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
@ 2012-03-12 15:17 Simon Wood
2012-03-12 15:17 ` [PATCH 2/2] HID: hid-lg4ff clean up attribution Simon Wood
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Simon Wood @ 2012-03-12 15:17 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, Jiri Kosina, Michael Bauer, Michal Maly, Simon Wood
This patch adds support for the G27 LEDs. The LEDs are controlled
by a 5bit value (0-31) where bit0 is the right most LED, the LEDs
are mirrored to the left.
Arrangement on wheel is:
G G Y Y R R(bit4) Y Y G G(bit0)
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/hid/hid-lg4ff.c | 84 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 6ecc9e2..4f3b744 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -49,7 +49,12 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid, u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute *attr, char *buf);
static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
+static void hid_lg4ff_set_leds(struct hid_device *hid, __u8 leds);
+static ssize_t lg4ff_leds_show(struct device *dev, struct device_attribute *attr, char *buf);
+static ssize_t lg4ff_leds_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
+
static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_range_show, lg4ff_range_store);
+static DEVICE_ATTR(leds, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_leds_show, lg4ff_leds_store);
static bool list_inited;
@@ -336,6 +341,67 @@ static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *at
return count;
}
+/* Read current state of leds and display it in terminal */
+static ssize_t lg4ff_leds_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct lg4ff_device_entry *uninitialized_var(entry);
+ struct list_head *h;
+ struct hid_device *hid = to_hid_device(dev);
+ size_t count;
+
+ list_for_each(h, &device_list.list) {
+ entry = list_entry(h, struct lg4ff_device_entry, list);
+ if (strcmp(entry->device_id, (&hid->dev)->kobj.name) == 0)
+ break;
+ }
+ if (h == &device_list.list) {
+ dbg_hid("Device not found!");
+ return 0;
+ }
+
+ count = scnprintf(buf, PAGE_SIZE, "%u\n", entry->leds);
+ return count;
+}
+
+static ssize_t lg4ff_leds_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct lg4ff_device_entry *uninitialized_var(entry);
+ struct list_head *h;
+ struct hid_device *hid = to_hid_device(dev);
+ __u8 leds = (__u8) simple_strtoul(buf, NULL, 10) & 0x1F; /* values 0 to 31 */
+
+ list_for_each(h, &device_list.list) {
+ entry = list_entry(h, struct lg4ff_device_entry, list);
+ if (strcmp(entry->device_id, (&hid->dev)->kobj.name) == 0)
+ break;
+ }
+ if (h == &device_list.list) {
+ dbg_hid("Device not found!");
+ return count;
+ }
+
+ /* Set leds to user specified value: 5 wide bit field for leds on right (mirrored to left) */
+ hid_lg4ff_set_leds(hid, leds);
+ entry->leds = leds;
+
+ return count;
+}
+
+static void hid_lg4ff_set_leds(struct hid_device *hid, __u8 leds)
+{
+ struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
+ struct hid_report *report = list_entry(report_list->next, struct hid_report, list);
+
+ report->field[0]->value[0] = 0xf8;
+ report->field[0]->value[1] = 0x12;
+ report->field[0]->value[2] = leds;
+ report->field[0]->value[3] = 0x00;
+ report->field[0]->value[4] = 0x00;
+ report->field[0]->value[5] = 0x00;
+ report->field[0]->value[6] = 0x00;
+ usbhid_submit_report(hid, report, USB_DIR_OUT);
+}
+
int lg4ff_init(struct hid_device *hid)
{
struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
@@ -446,17 +512,30 @@ int lg4ff_init(struct hid_device *hid)
entry->set_range = lg4ff_devices[i].set_range;
list_add(&entry->list, &device_list.list);
- /* Create sysfs interface */
+ /* Create sysfs interface for range */
error = device_create_file(&hid->dev, &dev_attr_range);
if (error)
return error;
- dbg_hid("sysfs interface created\n");
+ dbg_hid("sysfs interface created for range\n");
/* Set the maximum range to start with */
entry->range = entry->max_range;
if (entry->set_range != NULL)
entry->set_range(hid, entry->range);
+ /* Create sysfs interface for leds - G27 only */
+ if (rev_maj == G27_REV_MAJ && rev_min == G27_REV_MIN) {
+ error = device_create_file(&hid->dev, &dev_attr_leds);
+ if (error)
+ return error;
+
+ dbg_hid("sysfs interface created for leds\n");
+
+ /* Turn off all leds */
+ entry->leds = 0;
+ hid_lg4ff_set_leds(hid, 0);
+ }
+
hid_info(hid, "Force feedback for Logitech Speed Force Wireless by Simon Wood <simon@mungewell.org>\n");
return 0;
}
@@ -483,6 +562,7 @@ int lg4ff_deinit(struct hid_device *hid)
}
device_remove_file(&hid->dev, &dev_attr_range);
+ device_remove_file(&hid->dev, &dev_attr_leds);
dbg_hid("Device successfully unregistered\n");
return 0;
}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH 2/2] HID: hid-lg4ff clean up attribution
2012-03-12 15:17 [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Simon Wood
@ 2012-03-12 15:17 ` Simon Wood
2012-03-12 15:46 ` [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Jiri Kosina
2012-03-12 16:09 ` Jiri Kosina
2 siblings, 0 replies; 11+ messages in thread
From: Simon Wood @ 2012-03-12 15:17 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, Jiri Kosina, Michael Bauer, Michal Maly, Simon Wood
This patch adds proper attribution for Michal (who re-wrote significant
portions of this driver last year) and clarifies that it now supports
most of the Logitech gaming wheels (not just the Speed Force Wireless).
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/hid/Kconfig | 1 +
drivers/hid/hid-lg4ff.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a421abd..1a7fd8c 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -307,6 +307,7 @@ config LOGIWHEELS_FF
- Logitech G27
- Logitech MOMO/MOMO 2
- Logitech Formula Force EX
+ - Logitech Speed Force Wireless (Wii)
config HID_MAGICMOUSE
tristate "Apple MagicMouse multi-touch support"
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 4f3b744..bad760d 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -1,9 +1,13 @@
/*
- * Force feedback support for Logitech Speed Force Wireless
+ * Force feedback support for Logitech Gaming Wheels
+ *
+ * Including: MOMO, MOMO2, DFGT, DFP, G25, G27
+ * and Speed Force Wireless (Wii)
*
* http://wiibrew.org/wiki/Logitech_USB_steering_wheel
*
* Copyright (c) 2010 Simon Wood <simon@mungewell.org>
+ * Copyright (c) 2011 Michal Maly <madcatxster@gmail.com>
*/
/*
@@ -536,7 +540,7 @@ int lg4ff_init(struct hid_device *hid)
hid_lg4ff_set_leds(hid, 0);
}
- hid_info(hid, "Force feedback for Logitech Speed Force Wireless by Simon Wood <simon@mungewell.org>\n");
+ hid_info(hid, "Force feedback for Logitech Gaming Wheels\n");
return 0;
}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 15:17 [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Simon Wood
2012-03-12 15:17 ` [PATCH 2/2] HID: hid-lg4ff clean up attribution Simon Wood
@ 2012-03-12 15:46 ` Jiri Kosina
2012-03-12 18:04 ` simon
2012-03-12 16:09 ` Jiri Kosina
2 siblings, 1 reply; 11+ messages in thread
From: Jiri Kosina @ 2012-03-12 15:46 UTC (permalink / raw)
To: Simon Wood; +Cc: linux-input, linux-kernel, Michael Bauer, Michal Maly
On Mon, 12 Mar 2012, Simon Wood wrote:
> This patch adds support for the G27 LEDs. The LEDs are controlled
> by a 5bit value (0-31) where bit0 is the right most LED, the LEDs
> are mirrored to the left.
>
> Arrangement on wheel is:
> G G Y Y R R(bit4) Y Y G G(bit0)
Simon,
is there a usespace application operating on top of this?
Also, it'd be necessary to document this properly in Documentation/ABI.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 15:46 ` [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Jiri Kosina
@ 2012-03-12 18:04 ` simon
2012-03-12 18:07 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: simon @ 2012-03-12 18:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Simon Wood, linux-input, linux-kernel, Michael Bauer, Michal Maly
> On Mon, 12 Mar 2012, Simon Wood wrote:
>
>> This patch adds support for the G27 LEDs. The LEDs are controlled
>> by a 5bit value (0-31) where bit0 is the right most LED, the LEDs
>> are mirrored to the left.
>>
>> Arrangement on wheel is:
>> G G Y Y R R(bit4) Y Y G G(bit0)
>
> Simon,
>
> is there a usespace application operating on top of this?
At present no; I'd like to add this to Speed Dreams (www.speed-dreams.org)
racing simulator in the future, but this will likely take the form of a
3rd party script to read RPM/Redline and drive the sysfs interface
directly as very few user's setups will be alike.
At the moment you'd just drive the LEDs simply, ie:
$ echo 31 > /sys/bus/hid/devices/.../leds
>
> Also, it'd be necessary to document this properly in Documentation/ABI.
OK, I'll add a description to
'Documention/ABI/testing/sysfs-driver-hid-logitech-lg4ff'.
Should this move to 'stable' now as hid-lg4ff is in mainline now?
>> + list_for_each(h, &device_list.list) {
>> + entry = list_entry(h, struct lg4ff_device_entry, list);
>> + if (strcmp(entry->device_id, (&hid->dev)->kobj.name) == 0)
>> + break;
>> + }
>
> Please correct me if I am wrong, but I don't see nothing that'd prevent
> this racing with lg4ff_deinit().
>
> The same applies to already existing sysfs attributes actually.
I believe that Michal is working on some 'spin locking' in this area,
which might meet your requirements. But the patch he sent around last week
(off list) didn't lock on the deinit()...
Simon.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 18:04 ` simon
@ 2012-03-12 18:07 ` Mark Brown
2012-03-12 18:19 ` simon
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2012-03-12 18:07 UTC (permalink / raw)
To: simon; +Cc: Jiri Kosina, linux-input, linux-kernel, Michael Bauer,
Michal Maly
On Mon, Mar 12, 2012 at 02:04:14PM -0400, simon@mungewell.org wrote:
> At the moment you'd just drive the LEDs simply, ie:
> $ echo 31 > /sys/bus/hid/devices/.../leds
Shouldn't this be using the LED subsystem the kernel already has?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 18:07 ` Mark Brown
@ 2012-03-12 18:19 ` simon
2012-03-12 18:32 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: simon @ 2012-03-12 18:19 UTC (permalink / raw)
To: Mark Brown
Cc: simon, Jiri Kosina, linux-input, linux-kernel, Michael Bauer,
Michal Maly
> On Mon, Mar 12, 2012 at 02:04:14PM -0400, simon@mungewell.org wrote:
>
>> At the moment you'd just drive the LEDs simply, ie:
>> $ echo 31 > /sys/bus/hid/devices/.../leds
>
> Shouldn't this be using the LED subsystem the kernel already has?
>
The LED subsystem appears to be aim at controller chips (ie. lp3944) which
are connected to a bus (I2C) in a generalised form. I guess people might
be doing 'blinken light' type systems.
The LEDs on the G27 are very much more specific, mounted on the yoke of
the gaming wheel.
Would this require the use/complexity of the LED subsystem?
Simon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 18:19 ` simon
@ 2012-03-12 18:32 ` Mark Brown
2012-03-12 19:05 ` simon
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2012-03-12 18:32 UTC (permalink / raw)
To: simon; +Cc: Jiri Kosina, linux-input, linux-kernel, Michael Bauer,
Michal Maly
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]
On Mon, Mar 12, 2012 at 02:19:25PM -0400, simon@mungewell.org wrote:
> > On Mon, Mar 12, 2012 at 02:04:14PM -0400, simon@mungewell.org wrote:
> >> At the moment you'd just drive the LEDs simply, ie:
> >> $ echo 31 > /sys/bus/hid/devices/.../leds
> > Shouldn't this be using the LED subsystem the kernel already has?
> The LED subsystem appears to be aim at controller chips (ie. lp3944) which
> are connected to a bus (I2C) in a generalised form. I guess people might
> be doing 'blinken light' type systems.
Not really, it's aimed at supporting LEDs in general. Obviously most of
the drivers are for specific controller chips which makes them more
visible but there's also things like the triggers.
> The LEDs on the G27 are very much more specific, mounted on the yoke of
> the gaming wheel.
> Would this require the use/complexity of the LED subsystem?
Well, it'd mean that applications that know how to drive LEDs will be
able to use the LEDs on this wheel with less per device knowledge which
seems like a useful thing and if someone wants to remap a LED to "new
mail" or whatever that'll be easier (nethack has the mailer daemon
deliver a scroll of mail!).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 18:32 ` Mark Brown
@ 2012-03-12 19:05 ` simon
2012-03-12 19:12 ` Mark Brown
2012-03-13 8:23 ` Jiri Kosina
0 siblings, 2 replies; 11+ messages in thread
From: simon @ 2012-03-12 19:05 UTC (permalink / raw)
To: Mark Brown
Cc: simon, Jiri Kosina, linux-input, linux-kernel, Michael Bauer,
Michal Maly
>> The LEDs on the G27 are very much more specific, mounted on the yoke of
>> the gaming wheel.
>
>> Would this require the use/complexity of the LED subsystem?
>
> Well, it'd mean that applications that know how to drive LEDs will be
> able to use the LEDs on this wheel with less per device knowledge which
> seems like a useful thing and if someone wants to remap a LED to "new
> mail" or whatever that'll be easier (nethack has the mailer daemon
> deliver a scroll of mail!).
I'm not familiar with the LED subsystem, but my concerns would be that
this would add a whole load of code to implement.
Most of concern is the fact that the Logitech wheels are transitioned from
a 'simple' wheel when they are plugged in to an 'advanced' wheel, they
release/re-register with a different USB ID.
The port (for a lack of a better word) for controlling the LEDs is mixed
in with the FF and wheel configuration commands. All this is handled
within the hid-lg4ff driver (if FF is not enabled you just get the
'simple' wheel behaviour).
If you can point me at some (simple) implementations of the LED subsystem,
possibly with some guidance, we can look to see if the added complexity is
actually worth it.
I'd be pretty sure that other gaming controllers don't abstract their LEDs
via this subsystem,
Simon.
PS. I don't really care about email when screaming around Laguna Seca ;-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 19:05 ` simon
@ 2012-03-12 19:12 ` Mark Brown
2012-03-13 8:23 ` Jiri Kosina
1 sibling, 0 replies; 11+ messages in thread
From: Mark Brown @ 2012-03-12 19:12 UTC (permalink / raw)
To: simon; +Cc: Jiri Kosina, linux-input, linux-kernel, Michael Bauer,
Michal Maly
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On Mon, Mar 12, 2012 at 03:05:39PM -0400, simon@mungewell.org wrote:
> If you can point me at some (simple) implementations of the LED subsystem,
> possibly with some guidance, we can look to see if the added complexity is
> actually worth it.
I don't think any of the LED drivers are massively complex... you just
register and then you get a callback to set the brightness. That's
really all there is to it.
> I'd be pretty sure that other gaming controllers don't abstract their LEDs
> via this subsystem,
How sad :(
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 19:05 ` simon
2012-03-12 19:12 ` Mark Brown
@ 2012-03-13 8:23 ` Jiri Kosina
1 sibling, 0 replies; 11+ messages in thread
From: Jiri Kosina @ 2012-03-13 8:23 UTC (permalink / raw)
To: simon; +Cc: Mark Brown, linux-input, linux-kernel, Michael Bauer, Michal Maly
On Mon, 12 Mar 2012, simon@mungewell.org wrote:
> >> The LEDs on the G27 are very much more specific, mounted on the yoke of
> >> the gaming wheel.
> >
> >> Would this require the use/complexity of the LED subsystem?
> >
> > Well, it'd mean that applications that know how to drive LEDs will be
> > able to use the LEDs on this wheel with less per device knowledge which
> > seems like a useful thing and if someone wants to remap a LED to "new
> > mail" or whatever that'll be easier (nethack has the mailer daemon
> > deliver a scroll of mail!).
>
> I'm not familiar with the LED subsystem, but my concerns would be that
> this would add a whole load of code to implement.
Not really, it's rather simple to use and as Mark said, it's a proper
infrastructure to use here.
We already have HID drivers which are using this -- you can look at
PicoLCD or Wiimote drivers and you'll see that it's indeed fairly simple.
> PS. I don't really care about email when screaming around Laguna Seca ;-)
:))
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
2012-03-12 15:17 [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Simon Wood
2012-03-12 15:17 ` [PATCH 2/2] HID: hid-lg4ff clean up attribution Simon Wood
2012-03-12 15:46 ` [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Jiri Kosina
@ 2012-03-12 16:09 ` Jiri Kosina
2 siblings, 0 replies; 11+ messages in thread
From: Jiri Kosina @ 2012-03-12 16:09 UTC (permalink / raw)
To: Simon Wood; +Cc: linux-input, linux-kernel, Michael Bauer, Michal Maly
On Mon, 12 Mar 2012, Simon Wood wrote:
> This patch adds support for the G27 LEDs. The LEDs are controlled
> by a 5bit value (0-31) where bit0 is the right most LED, the LEDs
> are mirrored to the left.
>
> Arrangement on wheel is:
> G G Y Y R R(bit4) Y Y G G(bit0)
>
> Signed-off-by: Simon Wood <simon@mungewell.org>
> ---
> drivers/hid/hid-lg4ff.c | 84 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
> index 6ecc9e2..4f3b744 100644
> --- a/drivers/hid/hid-lg4ff.c
> +++ b/drivers/hid/hid-lg4ff.c
> @@ -49,7 +49,12 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid, u16 range);
> static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute *attr, char *buf);
> static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
>
> +static void hid_lg4ff_set_leds(struct hid_device *hid, __u8 leds);
> +static ssize_t lg4ff_leds_show(struct device *dev, struct device_attribute *attr, char *buf);
> +static ssize_t lg4ff_leds_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
> +
> static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_range_show, lg4ff_range_store);
> +static DEVICE_ATTR(leds, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_leds_show, lg4ff_leds_store);
>
> static bool list_inited;
>
> @@ -336,6 +341,67 @@ static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *at
> return count;
> }
>
> +/* Read current state of leds and display it in terminal */
> +static ssize_t lg4ff_leds_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct lg4ff_device_entry *uninitialized_var(entry);
> + struct list_head *h;
> + struct hid_device *hid = to_hid_device(dev);
> + size_t count;
> +
> + list_for_each(h, &device_list.list) {
> + entry = list_entry(h, struct lg4ff_device_entry, list);
> + if (strcmp(entry->device_id, (&hid->dev)->kobj.name) == 0)
> + break;
> + }
Please correct me if I am wrong, but I don't see nothing that'd prevent
this racing with lg4ff_deinit().
The same applies to already existing sysfs attributes actually.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-03-13 8:23 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-12 15:17 [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Simon Wood
2012-03-12 15:17 ` [PATCH 2/2] HID: hid-lg4ff clean up attribution Simon Wood
2012-03-12 15:46 ` [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs Jiri Kosina
2012-03-12 18:04 ` simon
2012-03-12 18:07 ` Mark Brown
2012-03-12 18:19 ` simon
2012-03-12 18:32 ` Mark Brown
2012-03-12 19:05 ` simon
2012-03-12 19:12 ` Mark Brown
2012-03-13 8:23 ` Jiri Kosina
2012-03-12 16:09 ` Jiri Kosina
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).