mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"David Herrmann" <dh.herrmann@gmail.com>,
	akpm@linux-foundation.org, jslaby@suse.cz,
	"Bryan Wu" <cooloney@gmail.com>,
	rpurdie@rpsys.net, linux-kernel@vger.kernel.org,
	"Evan Broder" <evan@ebroder.net>,
	"Arnaud Patard" <arnaud.patard@rtp-net.org>,
	"Peter Korsgaard" <jacmet@sunsite.dk>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Matt Sealey" <matt@genesi-usa.com>,
	"Rob Clark" <robdclark@gmail.com>,
	"Niels de Vos" <devos@fedoraproject.org>,
	linux-arm-kernel@lists.infradead.org,
	"Steev Klimaszewski" <steev@genesi-usa.com>,
	blogic@openwrt.org, "Pali Rohár" <pali.rohar@gmail.com>
Subject: Re: [PATCH] Route keyboard LEDs through the generic LEDs layer.
Date: Sat, 12 Apr 2014 18:30:49 -0700	[thread overview]
Message-ID: <20140413013049.GB28990@core.coreip.homeip.net> (raw)
In-Reply-To: <20140412100934.GA7196@amd.pavel.ucw.cz>

On Sat, Apr 12, 2014 at 12:09:34PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > 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 think we should deprecate LED controls using event devices. We have
> nice API for LEDs, and it is not in input.
> 
> 
> 
> 
> > > > 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).
> > 
> > This is not about amount of damage but the overall correctness of the
> > implementation. I'd rather not have a solution with known holes, if
> > possible.
> 
> I'd say that applications using direct EV_LED interface should just
> stop doing it. Yes, you can probably use led API and still toggle the
> led using gpio api behind leds back (not tested, perhaps there are
> interlocks that prevent that)... and it is same situation with
> EV_LED. We should just teach applications not to do that.
> 
> Would solution where EV_LED would be ignored when there's non-default
> trigger selected work for you?

Not ignored but rather routed to the LED that is currently selected for
given function. This way if I re-purposed CapsLock LED for Wifi and do
not provide a replacement EV_LED will be effectively dropped, but if I
switch CapsLock with NumLock I want the event to affect the appropriate
LED.

Thanks.

-- 
Dmitry

  reply	other threads:[~2014-04-13  1:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31 12:23 Samuel Thibault
2014-04-01  7:02 ` Pali Rohár
2014-04-07  2:10 ` Dmitry Torokhov
2014-04-07  7:54   ` Samuel Thibault
2014-04-08  8:39     ` Dmitry Torokhov
2014-04-08 23:33       ` Samuel Thibault
2014-04-11  6:12         ` Samuel Thibault
2014-04-13  1:25           ` Dmitry Torokhov
2014-04-16 23:38             ` Samuel Thibault
2014-04-12 10:09       ` Pavel Machek
2014-04-13  1:30         ` Dmitry Torokhov [this message]
2014-10-01 18:42 ` Andrew Morton
2014-10-01 21:29   ` Samuel Thibault
2014-10-12 14:52     ` Pali Rohár
2014-10-15 23:15       ` Samuel Thibault
2014-10-15 23:29         ` Pali Rohár
2014-12-09 17:12           ` Pali Rohár
2014-12-09 20:22             ` Peter Korsgaard
2014-12-10  1:03               ` Samuel Thibault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140413013049.GB28990@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnaud.patard@rtp-net.org \
    --cc=blogic@openwrt.org \
    --cc=cooloney@gmail.com \
    --cc=devos@fedoraproject.org \
    --cc=dh.herrmann@gmail.com \
    --cc=evan@ebroder.net \
    --cc=jacmet@sunsite.dk \
    --cc=jslaby@suse.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@genesi-usa.com \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=robdclark@gmail.com \
    --cc=rpurdie@rpsys.net \
    --cc=s.hauer@pengutronix.de \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=steev@genesi-usa.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®