linux-kernel - [PATCH 0/3] Switch input leds over to standard LED class devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon,  8 Jun 2015 14:43:07 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Pavel Machek <pavel@....cz>,
	Pali Rohár <pali.rohar@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	rpurdie@...ys.net, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: [PATCH 0/3] Switch input leds over to standard LED class devices 

Hi,

I finally was able to spend some time looking over Samuel's patch set
switching input LEDs from custom implementation over to standard LED class
devices and I think this is the shape I am reasonably happy with. The
changes:

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). The old way of controlling the leds (via writing
EV_LED/LED_XXX events into an event device) is still there and may override
LED state set up via a trigger or through sysfs attribute. Also when input
device is "grabbed" requests coming from LED subsystem are ignored until
the device is released.

2. There are no per-input device triggers. Input devices only carry LEDs
and those LEDs use one of the system-wide triggers. Which ones is to user
to decide. The default triggers are the one defines by keyboard handler for
it's standard LED states.

3. There are no VT "LEDs" combining state of multiple keyboards/input
devices anymore. 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).
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.

Please take a look and see if you see any holes.

Thanks.

-- 
Dmitry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/