linux-kernel - Re: [PATCH] Route keyboard LEDs through the generic LEDs layer.

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Apr 2014 01:33:06 +0200
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Pavel Machek <pavel@....cz>,
	David Herrmann <dh.herrmann@...il.com>,
	akpm@...ux-foundation.org, jslaby@...e.cz,
	Bryan Wu <cooloney@...il.com>, rpurdie@...ys.net,
	linux-kernel@...r.kernel.org, Evan Broder <evan@...oder.net>,
	Arnaud Patard <arnaud.patard@...-net.org>,
	Peter Korsgaard <jacmet@...site.dk>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Matt Sealey <matt@...esi-usa.com>,
	Rob Clark <robdclark@...il.com>,
	Niels de Vos <devos@...oraproject.org>,
	linux-arm-kernel@...ts.infradead.org,
	Steev Klimaszewski <steev@...esi-usa.com>, blogic@...nwrt.org,
	Pali Rohár <pali.rohar@...il.com>
Subject: Re: [PATCH] Route keyboard LEDs through the generic LEDs layer.

Hello,

Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a écrit :
> It is not about the VT, I am talking about pure input core. If I
> repurpose CapsLock LED for my WiFi indicator I do not want to go into
> other programs and teach them that they should stay away from trying to
> control this LED.

Err, but even without talking about repurposing Capslock LED for WiFi...
How is managed the conflict between the normal capslock behavior and
other programs' action on the underlying input device?  I don't think
this patch does not introduce the problem.

Now you may answer "well, if it could fix the problem along the way it'd
be good".  I'd like to answer "well, this is not my shit" :)

But still, the problem is interesting, and I don't know how to deal
properly with it. More precisely, I don't think we *want* to deal with
it.  Currently, what happens is that there is no priority between what
the VT keyboard events produce and what applications produce, so things
happily mix with strange results as soon as a user tries to combine
both. My concern is:

How to decide which one to prioritize?

Is it just because console-setup happens to repurpose the capslock LED
key that applications should suddenly not have capslock LED control
at all?  That's contradictory with the use case you have given.  That
leads me into believing that we should not try to push a hard rule, and
just let the user manage what accesses it.  We could indeed make the VT
always take priority, but then that would probably break some existing
applications.  Then, is "repurposing a keyboard LED" enough of an action
to be able to decide that applications modifying that LED should be just
ignored?  I doubt it.

> I understand the desire, however I still wonder if we should be
> extending legacy VT given that David wants to move it all to userspace.

I believe I have heard about moving the console implementation to
userland for more that a decide.  Will that really happen any time?
In the meanwhile, we have broken capslock keys on e.g. all Debian and
Ubuntu systems for a couple of years already (because they have adopted
console-setup), and some ARM systems don't have keyboard LEDs at all
without a patched kernel.

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