Re: Spurious touchpad events with closed LID

["Pali Rohár" <pali.rohar@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2570 bytes --]

On Monday 26 June 2017 19:03:12 Dmitry Torokhov wrote:
> 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.

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.

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

Exactly. Userspace receive all needed events and then tell kernel to 
"mute" input device based on own userspace policies.

> Drivers can also implement inhibit/uninhibit methods that can put
> inhibited devices into lower power mode.

Sounds good. Once events are not delivered to userspace, kernel does not 
have to receive them too and can power off that input device (if hw 
support such thing).

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

Can you send some links to that implementation/patch series?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]