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 -- 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
