linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
	devicetree-discuss@lists.ozlabs.org, john.stultz@linaro.org,
	kernel-team@android.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 2/2] Input: Adding DT support for keyreset tuneables
Date: Wed, 10 Jul 2013 09:52:47 -0700	[thread overview]
Message-ID: <20130710165247.GA22992@core.coreip.homeip.net> (raw)
In-Reply-To: <20130710151457.D0B863E1168@localhost>

On Wed, Jul 10, 2013 at 04:14:57PM +0100, Grant Likely wrote:
> On Fri, 28 Jun 2013 07:19:06 -0600, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > On 13-06-28 12:09 AM, Dmitry Torokhov wrote:
> > >>>> I do not agree.  We want the binding to be generic and not tied
> > >>>> specifically to the keyreset functionality.  As such 'input-keyset' or
> > >>>> 'input-keychord' are more appropriate.
> > >>>
> > >>> The binding is defined specifically for sysrq and specifically to
> > >>> perform reset action.
> > >>
> > >> Yes for now but as the examples in the binding show, it is easy to
> > >> envision how other drivers could use it.
> > > 
> > > I think you over-complicate things here. Unlike matrix-keypad binding,
> > > where you have a common parsing code, here we have an individual driver.
> > > I really do not see anyone else using such sequences or chords as such
> > > processing should be done in userspace. Sysrq is quite an exception.
> > 
> > To be honest I don't have a very strong opinion on the binding.  I made
> > it as generic as possible on the guidance of the DT people.  Let's see
> > what they think of it.
> 
> Hi Mathieu,
> 
> As per our conversation just now at Connect, the binding should probably
> look like this:
> 
> Sysrq keyset binding:
> 
> The /chosen node can contain a linux,input-keyset-sysrq child node to
> define a set of keys that will generate a sysrq when pressed together.

Hmm, we would have only one such node, /sysrq, or /linux,sysrq,
whatever. The sysrq setting is system-wide and applicable to all
devices. Given that it is used only on mobile, where there not that
many input devices (a few keys and touchscreen) I do not believe we
should consider adding per-device settings.

> 
> Required properties:
> keyset: array of keycodes

Please, let's call it 'key-reset-seq', because it is exactly the reset
sequence. There won't be any additional sequences or chords as those
should be handled in userspace, sysrq is a special case here.

> timeout-ms: duration keys must be pressed together in microseconds
> before generating a sysrq
> 

Thanks.

-- 
Dmitry

  reply	other threads:[~2013-07-10 16:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 16:13 [PATCH 1/2] Input: Add device tree bindings for input keys mathieu.poirier
2013-06-27 16:13 ` [PATCH 2/2] Input: Adding DT support for keyreset tuneables mathieu.poirier
2013-06-27 16:28   ` Dmitry Torokhov
2013-06-27 16:28     ` Dmitry Torokhov
2013-06-27 17:56     ` Mathieu Poirier
2013-06-27 18:25       ` Dmitry Torokhov
2013-06-27 18:42         ` Mathieu Poirier
2013-06-28  6:09           ` Dmitry Torokhov
2013-06-28 13:19             ` Mathieu Poirier
2013-07-10 15:14               ` Grant Likely
2013-07-10 16:52                 ` Dmitry Torokhov [this message]
     [not found]                   ` <20130710165247.GA22992-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2013-07-10 21:35                     ` Mathieu Poirier
2013-07-10 21:50                   ` Grant Likely
2013-07-10 22:20                     ` Dmitry Torokhov
     [not found]                       ` <3572203.AkEVm8LFzu-wUGeVx6es1+Q2O5dskk9LyLysJ1jNyTM@public.gmane.org>
2013-07-10 22:29                         ` Mathieu Poirier
2013-07-10 22:55                           ` Dmitry Torokhov

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=20130710165247.GA22992@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linux-input@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    /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;
as well as URLs for NNTP newsgroup(s).