All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: Spurious touchpad events with closed LID
Date: Wed, 28 Jun 2017 22:15:30 +0200	[thread overview]
Message-ID: <20170628201530.GB18101@amd> (raw)
In-Reply-To: <201706262109.42628@pali>

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

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.
> 
> Hm... this sounds like a "disable" property for each event device which 
> I was talking about months ago (ccing Pavel). Very similar problem is on 
> Nokia N900, where touchscreen needs to be turned off when screen is 
> locked and phone in pocket.

Yes, disable property would be nice.

> > 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.

While policy normally belongs to userspace, I'd argue this is
workaround for a hardware bug, and in-kernel solution would be
acceptable.

Anyway, disable attribute would be nice first step.

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-06-28 20:15 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
2017-06-26 19:09   ` Pali Rohár
2017-06-28 20:15     ` Pavel Machek [this message]
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=20170628201530.GB18101@amd \
    --to=pavel@ucw.cz \
    --cc=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.