Date:	Mon, 7 Apr 2014 09:54:23 +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.

Dmitry Torokhov, le Sun 06 Apr 2014 19:10:15 -0700, a écrit :
> On Mon, Mar 31, 2014 at 02:23:23PM +0200, Samuel Thibault wrote:
> > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > state, by adding keyboard led and modifier triggers connected to a series
> > of VT input LEDs, themselves connected to VT input triggers, which
> > per-input device LEDs use by default.  Userland can thus easily change the LED
> > behavior of (a priori) all input devices, or of particular input devices.
> > 
> 
> I still have the same concern that I believe I already mentioned a while
> ago: how do we reconcile the LED control via triggers with LED control
> done through event devices?

I don't remember that raised during the discussion.

> Currently, as far as I can see, they will be
> clashing with each other. I.e. if I remap my capslock led to be the new
> shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
> my new "shift lock", right?

Well, yes, sure, if you shoot in your foot it will hurt :) (although
here the damage is really small, it is just LED lighting or not).

I don't see why people would both tinker with such triggers and run
userland programs writing to evdev.  Of course it typically happens with
X, but that's not a problem in the usual case: kbd triggers are not
doing anything while on X, so X can play with evdev with no problem.
If the user puts e.g. a heartbeat on some LED and then runs X, the X
events will mix with the heartbeat.  The solution is for the user to
just disable the corresponding LED in the X keyboard configuration.
Do we really want to impose some overriding between VT-generated and
other application-generated events?  AIUI, we don't do this between
applications which would open the same evdev, so I don't see why we
should care more about the VT.

> Also I wonder if we really need to have the multiplexing (VT-level) leds
> in addition to per-device ones.

We do: we want to be able to easily remap all (current and future)
keyboards' LEDs easily.

My goal, at the beginning, was to be able to fix the console-setup
bug.  That was that console-setup wants to use, for the capslock key,
something else than the capslock mechanism hard-wired in the kernel,
so as to get way more fine-grain control over how caps is handled.
But then the capslock LED would not lit any more.  By remapping the
VT-level capslock led to the foo-lock used by console-setup, one gets
back capslock LEDs of all keyboards working back as expected by the
user.  I also use it for getting a group LED, just like I have on X,
to know which keyboard layout group I am in.  People using non-latin
layouts really need that.

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/

Powered by blists - more mailing lists