[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120312183235.GA28451@opensource.wolfsonmicro.com>
Date: Mon, 12 Mar 2012 18:32:35 +0000
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: simon@...gewell.org
Cc: Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, Michael Bauer <michael@...auer.org>,
Michal Maly <madcatxster@...il.com>
Subject: Re: [PATCH 1/2] HID: hid-lg4ff add support for G27 LEDs
On Mon, Mar 12, 2012 at 02:19:25PM -0400, simon@...gewell.org wrote:
> > On Mon, Mar 12, 2012 at 02:04:14PM -0400, simon@...gewell.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!).
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists