Bug 106435 - RFE: Enable middle-button-drag coexisting with scroll emulation
Summary: RFE: Enable middle-button-drag coexisting with scroll emulation
Status: RESOLVED WONTFIX
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-08 04:34 UTC by John
Modified: 2018-05-29 04:54 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description John 2018-05-08 04:34:15 UTC
I have a Trackpoint mouse ("eraser mouse") and when scroll wheel emulation is enabled there's no way to do a middle-button-drag, because as soon as you hold down the middle mouse button, it activates the scroll wheel emulation.

The thought I had, and I admit this is hacky and I'm open to suggestions, was that if you hold the middle mouse button down for a threshold amount of time without moving the pointer, it would switch back from scroll wheel emulation to normal behaviour (where the middle button is acting like a middle button again).  So you can do a middle-button-drag, you just have to hold the mouse button down for say 1 second before you can start dragging.  Not perfect, but certainly better than not ever being able to do it at all.

I'd say this functionality would probably require two new configurable values:

1. The amount of time (in milliseconds) you have to hold the middle button down (or both buttons down, if it's a two-button setup where the middle button itself is being emulated)
2. The distance the mouse is allowed to move during the delay without triggering scroll emulation

In other words, if the settings above were "1000 ms" and "10 pixels", then you'd have to hold the button for one second and keep the pointer within a 10-pixel radius to initiate a middle-button-drag.

There's also a related question of whether the user should be notified that the operational switch has occurred (and if so, how)?  Personally I'm fine with no notification and just doing it by muscle memory, but I'm sure I'd be happy with other approaches as well.
Comment 1 Peter Hutterer 2018-05-29 04:54:03 UTC
No, sorry. This feature is going to be virtually undiscoverable if it's hidden within libinput and based on timeouts and movement thresholds. The latter is difficult anyway, especially on trackpoints. We don't really have a notion of "pixels" because we don't know the screens.

What you want is something that is mutually exclusive. Either you get button scroll or you get button drag. But it's the same physical interaction from the POV of the device.

A better solution here would be to move the scroll button to a button you don't need for dragging. Or use a device that doesn't rely on middle button+drag for scrolling.

Sorry, not something that I'll add to libinput.


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.