From: Mark Rutland <mark.rutland@arm.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Daniel Mack <daniel@zonque.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"dh.herrmann@gmail.com" <dh.herrmann@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2] Input: Add driver for Microchip's CAP1106
Date: Tue, 15 Jul 2014 18:17:40 +0100 [thread overview]
Message-ID: <20140715171740.GA26068@leverpostej> (raw)
In-Reply-To: <20140715164149.GA40351@core.coreip.homeip.net>
On Tue, Jul 15, 2014 at 05:41:49PM +0100, Dmitry Torokhov wrote:
> Hi Mark,
>
> On Tue, Jul 15, 2014 at 09:51:38AM +0100, Mark Rutland wrote:
> > On Mon, Jul 14, 2014 at 11:20:17AM +0100, Daniel Mack wrote:
> > >
> > > linux,keycode feels a bit overkill here though, so I'd rather go for a
> > > fixed-size linux,keycodes property. The number of entries is fixed,
> > > anyway. Would you be fine with that?
> >
> > Assuming no-one's likely to want a sparse keymap (i.e. one where some
> > keys do nothing) then that's probably ok.
>
>
> For such a small keymap, if one does not want to use some of the
> buttons, setting corresponding entries to KEY_RESERVED should work well.
Ah, I was not aware of KEY_RESERVED. That sounds perfect then.
> > >
> > > I took that from the gpio-keys driver. Is there a better way to denote
> > > such a feature?
> >
> > Unfortunately not, given current practice. My gripe is that it's a Linux
> > detail that were describing rather than a property of the device. We can
> > forget about that for now.
>
> I prefer looking at it as user expressing the desired behavior of the
> driver; it is up to OS to deliver such behavior ;)
Sure, but the user and DTB author are not the same, and may have
different preferences. Additionally autorepeat as a property only tells
half the story; I might prefer a 1ms delay while my neighbour Joe might
like a 3 billion year delay (he's a bit like that, Joe is). He also only
wants the esc key to repeat and can't figure out how to express that in
this DTB thing he's never heard of.
We can just leave this with me grumbling if you prefer ;)
Thanks,
Mark.
prev parent reply other threads:[~2014-07-15 17:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 10:06 [PATCH v2] Input: Add driver for Microchip's CAP1106 Daniel Mack
2014-07-14 9:52 ` Mark Rutland
2014-07-14 10:20 ` Daniel Mack
2014-07-15 8:51 ` Mark Rutland
2014-07-15 9:12 ` Daniel Mack
2014-07-15 14:42 ` Mark Rutland
2014-07-15 16:41 ` Dmitry Torokhov
2014-07-15 17:17 ` Mark Rutland [this message]
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=20140715171740.GA26068@leverpostej \
--to=mark.rutland@arm.com \
--cc=broonie@kernel.org \
--cc=daniel@zonque.org \
--cc=devicetree@vger.kernel.org \
--cc=dh.herrmann@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.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).