Bug 92674 - RFE: Disable inaccessible devices
Summary: RFE: Disable inaccessible devices
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
: 93527 (view as bug list)
Depends on: 86223
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-26 13:57 UTC by Bastien Nocera
Modified: 2017-02-17 05:59 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed GUI (29.63 KB, image/png)
2016-01-10 17:02 UTC, Joao Machado
Details

Description Bastien Nocera 2015-10-26 13:57:10 UTC
When a touchpad, keyboard or trackstick is under a closed lid, there is no way to access it, and we should act as if the device was unplugged.

This might be implemented directly in libinput, or in the compositor. But compositors would need to know whether the various input devices would be hidden under the lid or not. libinput should expose that.
Comment 1 Carlos Garnacho Parro 2015-10-26 14:10:49 UTC
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.
Comment 2 Peter Hutterer 2015-10-26 21:10:46 UTC
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.
Comment 3 Peter Hutterer 2015-11-09 06:45:59 UTC
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.
Comment 4 Peter Hutterer 2016-01-04 00:31:36 UTC
*** Bug 93527 has been marked as a duplicate of this bug. ***
Comment 5 Peter Hutterer 2016-01-05 05:38:43 UTC
Related to bug 86223
Comment 6 Joao Machado 2016-01-10 17:02:26 UTC
Created attachment 120936 [details]
Proposed GUI

A proposed gui for Gnome Settings, purely for demonstration only.
Comment 7 Joao Machado 2016-01-10 17:23:12 UTC
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.
Comment 8 Peter Hutterer 2016-01-11 00:01:18 UTC
(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.
Comment 9 Josh Triplett 2016-09-13 22:50:23 UTC
(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.
Comment 10 Peter Hutterer 2017-02-17 05:59:48 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.