linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Henrik Rydberg <rydberg@euromail.se>,
	Chris Bagwell <chris@cnpbagwell.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	Nikolai Kondrashov <spbnick@gmail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Documentation: Add evdev type and code definitions
Date: Fri, 7 Jan 2011 14:42:02 -0800	[thread overview]
Message-ID: <20110107224202.GG28875@core.coreip.homeip.net> (raw)
In-Reply-To: <4D278DC6.7070209@canonical.com>

On Fri, Jan 07, 2011 at 05:03:50PM -0500, Chase Douglas wrote:
> On 01/07/2011 04:53 PM, Dmitry Torokhov wrote:
> > Hi Chase,
> > 
> > On Fri, Jan 07, 2011 at 04:28:15PM -0500, Chase Douglas wrote:
> >> +
> >> +EV_SW:
> >> +----------
> >> +EV_SW events describe stateful binary switches. For example, the SW_LID code is
> >> +used to denote when a laptop lid is closed.
> > 
> > Please add that drivers should refresh switch state upon binding to a
> > device and also upon resume.
> 
> I've not written any switch evdev drivers, can you clarify what you
> mean, maybe give me something to paste in?
> 
> Are you meaning that the switch state may have physically changed, and
> that the driver should query the physical state to be sure, or do you

Right, switch state might be physically changed while the device/system
was asleep and thus we need to ensure that kernel's (and userspace)
switch state is consistent with physical state.

Same should be done in the very beginnning, while registering input
device - it is quite possible that we start with some switches in
"on" state.

Technically speaking, some keys might be depressed as well, but we
ignore this possibility and assume that everything is released because
it is simpler, we expect that all depressed keys will be released
shortly anyway, and not all devices allow to query current state of a
button (i.e. devices that only transmit state change).

> mean that the driver must send a new event even if the state has not
> changed?

The drive should send the events and input core will filter them out if
state still matches the old state.

Thanks.

-- 
Dmitry

  reply	other threads:[~2011-01-07 22:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 21:28 [PATCH v2] Documentation: Add evdev type and code definitions Chase Douglas
2011-01-07 21:53 ` Dmitry Torokhov
2011-01-07 22:03   ` Chase Douglas
2011-01-07 22:42     ` Dmitry Torokhov [this message]
2011-01-07 22:06 ` Nikolai Kondrashov
2011-01-07 22:15   ` Chase Douglas
2011-01-07 22:26     ` Nikolai Kondrashov
2011-01-07 22:36       ` Chase Douglas
2011-01-08  1:15 ` Chris Bagwell
2011-01-09 14:51 ` Henrik Rydberg

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=20110107224202.GG28875@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=chase.douglas@canonical.com \
    --cc=chris@cnpbagwell.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.hutterer@who-t.net \
    --cc=rydberg@euromail.se \
    --cc=spbnick@gmail.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;
as well as URLs for NNTP newsgroup(s).