Bug 92674

Not sure what would be the best level to implement something like this tbh. libinput already has libinput_config_send_events_mode which gets in somewhat similar business I'd say, although it would need to fetch lid/tablet status internally too, which the compositor might find interesting too.

I'm happy to export the lid switch, but I'm not sure yet the actual logic for this should be in libinput, especially since the compositor may do other things for the lid switch. A call to change the sendevents mode to disabled would be better, though that requires the compositor to know which device is an internal touchpad - that's what we're currently lacking. We know it internally, but don't export it at this point.

A thread on the wayland-devel list that requests the same
http://lists.freedesktop.org/archives/wayland-devel/2015-November/025324.html

TLDR from my answer is: if the touchpad is inaccessible once the switch is triggered, I consider this a hw feature and we can add (silent) support for that in libinput. If it's a policy-based behaviour then it should be a compositor thing.

*** Bug 93527 has been marked as a duplicate of this bug. ***

Related to bug 86223

Created attachment 120936 [details]
Proposed GUI

A proposed gui for Gnome Settings, purely for demonstration only.

I just added an attachment, in hopes of helping this issue along. I just wish to offer some input from a users point of view. 

I originally posted this thread: https://bugzilla.gnome.org/show_bug.cgi?id=759745

We have two user senarios; One is that a user uses a laptop  connected to an external monitor via the Display Port, but keeps the laptop closed, they only want to use the big monitor. When they close the lid and the display is switched to the external monitor, the touchpad/trackpad goes nuts due to the sensitivity. So, in this case, the when the lid is closed, the internal touchpad/trackpad should be disabled automatically. But this setting should be system wide, not just a user setting. Because of the system is restarted with the lid closed, we don't want the touchpad/trackpad enabled.

The second scenario, is when a user decides to quickly move locations, say from their desk to a conference room, they don't want to put the machine to sleep or shut down.  Again, the touchpad/trackpad should be disabled automatically.

Now, the user should have control over this, there may be a scenario where they never want the touchpad/trackpad disabled, not sure what that may be, but you never know what hardware could show up on the scene.

Anyway, I have a temporary work around using custom keyboard shortcuts as stated in the link above but the users are not too keen on having to do that all of the time.

(In reply to Joao Machado from comment #7)
> Now, the user should have control over this, there may be a scenario where
> they never want the touchpad/trackpad disabled, not sure what that may be,
> but you never know what hardware could show up on the scene.

I'd say you can worry about that when the hardware appears. Until then, it's a needless item that just increases maintenance costs.

(In reply to Joao Machado from comment #7)
> One is that a user uses a laptop  connected to an
> external monitor via the Display Port, but keeps the laptop closed, they
> only want to use the big monitor. When they close the lid and the display is
> switched to the external monitor, the touchpad/trackpad goes nuts due to the
> sensitivity. So, in this case, the when the lid is closed, the internal
> touchpad/trackpad should be disabled automatically.

This is the exact scenario I've run into on multiple laptops: I have to leave the lid open when docked or the mouse dances across the screen and clicks randomly.

fixed with the series ending with

commit dc15a42d6cae4195d327253f6f05b65665eb3a93
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Jan 30 12:58:37 2017 +1000

    switch: for surface 3 tablets, write the lid open to the device