> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
