Messages in this thread |  | | Date | Wed, 10 Jun 2015 08:34:43 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH 1/3] Input: export LEDs as class devices in sysfs |
| |
On Tue 2015-06-09 09:49:35, Dmitry Torokhov wrote: > On Tue, Jun 09, 2015 at 03:19:55PM +0200, Samuel Thibault wrote: > > Hello, > > > > Dmitry Torokhov, le Mon 08 Jun 2015 14:43:08 -0700, a écrit : > > > 1. Instead of making LED class devices part of the input device they are > > > implemented as an input handler (and thus are completely separate from > > > input core). > > > > That's nicer indeed. Not defining triggers per LED however does not > > permit to e.g. switch two leds of a keyboard independently of what > > produces input events. I'm personally fine with it, I just wanted to > > mention it since this example of usage was cited at some point in the > > thread. > > I might have over-though the issue a bit in the past ;) But I think I am > happy with the current behavior, it separates input events and leds and > just says that you can select what tgrigges led state change. And you > shoudl still be able to do: > > echo "kbd-ctrlllock" > /sys/..../input22::caps-lock/trigger > echo "heartbit" > /sys/..../input22::num-lock/trigger > echo "kbd-numlock" > /sys/..../input22::scroll-lock/trigger > > But you can't say that pressing CapsLock on keyboard1 should light up > ScrollLock led on keyboard2, nor do we want it I think. If such control > is truly needed userspace can take over and managed leds as it sees fit, > like X does.
Ack. Please keep it simple. Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|  |