All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: Spurious touchpad events with closed LID
Date: Mon, 26 Jun 2017 10:03:12 -0700	[thread overview]
Message-ID: <20170626170312.GB4965@dtor-ws> (raw)
In-Reply-To: <201706261854.53970@pali>

On Mon, Jun 26, 2017 at 06:54:53PM +0200, Pali Rohár wrote:
> Hi!
> 
> When I'm using dock with external input devices (keyboard + mouse) and 
> LID is closed, I'm getting spurious touchpad events and random mouse 
> clicks and movements.
> 
> It is because top part of LID is above touchpad and probably generates 
> touch pushes.
> 
> Year (or two?) when I had conversation with ALPS people I was told that 
> Windows driver is automatically turning touchpad off when ACPI LID close 
> event is received (and similarly turn touchpad on).
> 
> Maybe Linux should do similar thing? Random movement or touchpad clicks 
> is really annoying. But I'm not sure if kernel or userspace should do 
> this job... What do you think?

It is a matter of policy (deciding when device is "usable") and this
should be controlled from userspace. Kernel should provide necessary
knobs for it though. For a long time I was saying that it should be done
at device core level, but I do not think we will ever get there.

On ChromeOS input devices export "inhibit" attribute that basically
overrides open/close count and prevents delivery of events to userspace,
and power management driver controls this attribute together with wake
up and others. This allows us to implement policies like "the touchpad
should only be active and a wakeup source while the device is in laptop
mode, but not in tablet or tent mode, or when lid is closed", "disable
keyboard in tablet mode or when list is closed", etc.

Drivers can also implement inhibit/uninhibit methods that can put
inhibited devices into lower power mode. I am not too happy with the
implementation (I'd like to see if we could merge inhibit/uninhibit and
open/close), that is why I haven't pushed it upstream yet.

Thanks.

-- 
Dmitry

  reply	other threads:[~2017-06-26 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 16:54 Spurious touchpad events with closed LID Pali Rohár
2017-06-26 17:03 ` Dmitry Torokhov [this message]
2017-06-26 19:09   ` Pali Rohár
2017-06-28 20:15     ` Pavel Machek
2017-06-28 22:44       ` Bastien Nocera
2017-06-29  7:31         ` Pali Rohár
2017-06-29 10:08           ` Pavel Machek
2017-06-29 10:11             ` Pali Rohár
2017-06-29 10:15               ` Pavel Machek
2017-06-29 10:24                 ` Pali Rohár
2017-06-29 10:37           ` Bastien Nocera

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=20170626170312.GB4965@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali.rohar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.