From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753636AbbFIORl (ORCPT ); Tue, 9 Jun 2015 10:17:41 -0400 Received: from sonata.ens-lyon.org ([140.77.166.138]:50711 "EHLO sonata.ens-lyon.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbbFIORd (ORCPT ); Tue, 9 Jun 2015 10:17:33 -0400 Date: Tue, 9 Jun 2015 16:17:23 +0200 From: Samuel Thibault To: Dmitry Torokhov Cc: Pavel Machek , Pali =?iso-8859-1?Q?Roh=E1r?= , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, rpurdie@rpsys.net, Greg Kroah-Hartman , 514464@bugs.debian.org, anton@lml.bas.bg Subject: Re: caps lock led does not show up Message-ID: <20150609141723.GE3045@type> Mail-Followup-To: Samuel Thibault , Dmitry Torokhov , Pavel Machek , Pali =?iso-8859-1?Q?Roh=E1r?= , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, rpurdie@rpsys.net, Greg Kroah-Hartman , 514464@bugs.debian.org, anton@lml.bas.bg MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1433799790-31873-1-git-send-email-dmitry.torokhov@gmail.com> <20090205113908.GA14224@const.inria.fr> 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 Hello, Samuel Thibault, le Thu 05 Feb 2009 12:39:08 +0100, a écrit : > And about the led issue, we need to ask the kernel for an interface to > be able to configure which lock should drive which led. Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit : > If user wants all keyboards to light up CapsLock LED when VT state locks > CtrlL modifier they need to write a udev rule or similar to set up > "kbd-ctrlllock" trigger for all appearing "input%::capslock" LED class > devices. Anton, this is the interface proposed by the input maintainer, Dmitry, to change which modifiers gets to light the keyboard LEDs (the exact names may change, but the principle should be firm). I know this is inconvenient for console-setup for handling hotplugged keyboards, but Dmitry prefers to avoid introducing a virtual multiplexer as explained below: > Having such virtual multiplexing object just adds complexity and is > hard to untange (see /dev/input/mice and all the issues we had with > synaptics driver trying to exclude it's data stream from it). Samuel