Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030207AbbFER5g (ORCPT ); Fri, 5 Jun 2015 13:57:36 -0400 Received: from sonata.ens-lyon.org ([140.77.166.138]:36054 "EHLO sonata.ens-lyon.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbbFER5c (ORCPT ); Fri, 5 Jun 2015 13:57:32 -0400 X-Greylist: delayed 559 seconds by postgrey-1.27 at vger.kernel.org; Fri, 05 Jun 2015 13:57:32 EDT Date: Fri, 5 Jun 2015 20:58:06 +0530 From: Samuel Thibault To: Dmitry Torokhov Cc: Pali =?iso-8859-1?Q?Roh=E1r?= , Pavel Machek , Andrew Morton , David Herrmann , Jiri Slaby , Bryan Wu , Richard Purdie , lkml , Evan Broder , Arnaud Patard , Peter Korsgaard , Sascha Hauer , Rob Clark , Niels de Vos , "linux-arm-kernel@lists.infradead.org" , blogic@openwrt.org Subject: Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer Message-ID: <20150605152806.GE2267@type> Mail-Followup-To: Samuel Thibault , Dmitry Torokhov , Pali =?iso-8859-1?Q?Roh=E1r?= , Pavel Machek , Andrew Morton , David Herrmann , Jiri Slaby , Bryan Wu , Richard Purdie , lkml , Evan Broder , Arnaud Patard , Peter Korsgaard , Sascha Hauer , Rob Clark , Niels de Vos , "linux-arm-kernel@lists.infradead.org" , blogic@openwrt.org References: <20150217191527.GA9594@type.youpi.perso.aquilenet.fr> <201504012200.07408@pali> <20150401211140.GI2901@type.youpi.perso.aquilenet.fr> <20150402144410.GB18125@amd> <20150423165544.GG7646@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1477 Lines: 37 Hello, Dmitry Torokhov, le Thu 23 Apr 2015 10:04:49 -0700, a ?crit : > One thing that I know we'd have to fix is that input device must be > "opened" before we can engage it, right now LED interface violates > this requirement. What do you mean precisely by "engage"? In the following, I guess actually calling dev->event(EV_LED) > It works right now because keyboard handler attaches > to most input devices with LEDs early enough for it to be > unnoticeable, but it does not mean that it is correct. It might be as > easy as calling input_open() unconditionally if devices has LEDs. This seems like only a workaround, perhaps it should rather be leds.c which checks for dev->users before calling dev->event(EV_LED)? > Another issue is that I do not think we should be introducing virtual > VT leds. I believe LEDs should belong to real devices; But then how to fix console-setup's bug? (it was actually the starter for all this work) See http://bugs.debian.org/514464 console-setup needs a way to tell which kbd modifier should toggle the capslock LED on all the keyboards used by the VT. Thus the point of VT leds, which people can use to decide the LED behavior of all keyboards, including hotplugged ones etc. Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/