Bug 1249309 - No drag lock
Summary: No drag lock
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-libinput
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-01 13:48 UTC by Tom Horsley
Modified: 2015-09-18 20:51 UTC (History)
4 users (show)

Fixed In Version: 0.14.0-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-18 20:51:52 UTC
Type: Bug


Attachments (Terms of Use)
Xorg.0.log with new libinput X driver installed (31.28 KB, text/plain)
2015-08-11 11:54 UTC, Tom Horsley
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 85577 0 None None None Never
GNOME Bugzilla 753341 0 None None None 2019-07-11 11:33:14 UTC

Description Tom Horsley 2015-08-01 13:48:16 UTC
Description of problem:

On fedora 20, this script works perfectly:

#!/bin/bash
xinput --set-button-map \
       'Kensington      Kensington Expert Mouse' \
       1 8 3 4 5 6 7 2
xinput --set-int-prop \
       'Kensington      Kensington Expert Mouse' \
       'Evdev Drag Lock Buttons' 8 2 1

On fedora 22, I see the same device and property names, but nothing happens with drag lock, it is like it is completely ignored. If I run xev and click button 8,
I get an immediate press/release button 8 sequence, no hint that I might be
doing a button 1 drag operation.

Version-Release number of selected component (if applicable):
xorg-x11-drv-evdev-2.9.2-1.fc22.x86_64

How reproducible:
100%

Steps to Reproduce:
1.run the above script
2.get no drag lock
3.

Actual results:
no drag lock

Expected results:
button 1 drag lock when I use the button now mapped to button 8

Additional info:
On the off chance that the code started using the post-map button numbers instead of the pre-map button numbers, I tried button 8 instead of button 2,
but still got no drag lock. I also tried 16 and 32 formats in addition to
format 8, still no drag lock.

Comment 1 Tom Horsley 2015-08-02 00:56:11 UTC
When I query the properties of the mouse, it does indeed tell me that the drag lock buttons property is set to the pair that I gave it. In my desperation for getting drag lock to work, I've been poking around in the evdev code, and since the lock pair is clearly stashed in the driver structure correctly, the only thing I can imagine is that something is going wrong with getting the event properly. I see lots of layers of static functions which are pretty much the same between f20 and f22, but up near the top of the call chain, the EvdevReadInput()
function is almost entirely different. I get lost about there, but my current totally non-expert theory is that is the most likely source of things going wrong but I certainly am not very familiar with any of this code, so it probably isn't a very good theory :-).

Comment 2 Tom Horsley 2015-08-02 22:35:11 UTC
AAUGH! After spending most of the weekend poking around, I finally discover that X isn't using evdev any more, it is using libinput, and libinput DOESN'T SUPPORT DRAG LOCK! Gah! Why do people make "improved" plug in replacements that aren't plug in replacements?

Why does xinput list-props show 'Evdev Drag Lock Buttons' as a property I can set if X isn't using evdev?

Fortunately I discovered a simple command to get drag lock working again:

dnf erase xorg-x11-drv-libinput

Comment 3 Peter Hutterer 2015-08-02 23:12:41 UTC
(In reply to Tom Horsley from comment #2)
> Why does xinput list-props show 'Evdev Drag Lock Buttons' as a property I
> can set if X isn't using evdev?

because your xinput command creates that property. use 
   xinput set-prop "device" "property name" <values>
instead and it'll complain when the property doesn't exist. --set-int-prop has been listed as deprecated in the man page since 2009.

so, now to the real issue, why do you need drag lock, how do you use it, what general and specific use-cases do you have that need to be accommodated. The reason I ask is to get a better understanding on why this feature is used and whether there are other ways to provide the same functionality with better outcomes.

Comment 4 Tom Horsley 2015-08-03 00:20:38 UTC
>now to the real issue, why do you need drag lock, how do you use it

That's easy: Get a trackball. Try to use it without drag lock. Hurl computer off high building after about an hour :-).

Trackballs are wonderful. They sit in one place, they don't need lots of room to use. Ones like the Kensington I use have very large balls which gives you great positioning sensitivity. You can take your hand off the ball, and press a button without having the mouse move because you pressed a button (good for games like neverputt :-), but you can't drag the mouse a long way while holding down a key with one hand without contorting your fingers into a pretzel or accidentally dropping the thing you are dragging God knows where. Hence the need for drag lock.

Windows has a feature that auto-enables drag lock if you hold a button down a long time. To forestall the idea that the Windows way is better, let me say here that I find it insane because I have no feel for what a "long time" is, so I never have any idea if the lock has happened or not, which leads to all sorts of strange results. I know when I have explicitly enabled a lock on linux, I never have any idea when Windows has implicitly enabled one.

On the other hand, I've never understood why things like drag lock and middle button emulation were down in the low level driver. I think it would be wonderful to have stuff like this at a higher level, and even user scriptable so I could do things like reassign some of those silly extra unneeded "media" function keys they keep adding to keyboards to be mouse buttons instead (thus giving me a button I can push without making the mouse move even for a regular mouse, or giving me a 2nd and 3rd mouse button even for an Apple computer :-).

Comment 5 Peter Hutterer 2015-08-03 05:23:53 UTC
(In reply to Tom Horsley from comment #4)
> >now to the real issue, why do you need drag lock, how do you use it
> 
> That's easy: Get a trackball. Try to use it without drag lock. Hurl computer
> off high building after about an hour :-).
> 
> Trackballs are wonderful. They sit in one place, they don't need lots of
> room to use. Ones like the Kensington I use have very large balls which
> gives you great positioning sensitivity. You can take your hand off the
> ball, and press a button without having the mouse move because you pressed a
> button (good for games like neverputt :-), but you can't drag the mouse a
> long way while holding down a key with one hand without contorting your
> fingers into a pretzel or accidentally dropping the thing you are dragging
> God knows where. Hence the need for drag lock.

how are you holding the trackball? I have a M570 here and the ball is operated with the thumb, so holding a button down while using the ball pretty much the same as any other trackball movement.


> Windows has a feature that auto-enables drag lock if you hold a button down
> a long time. To forestall the idea that the Windows way is better, let me
> say here that I find it insane because I have no feel for what a "long time"
> is, so I never have any idea if the lock has happened or not, which leads to
> all sorts of strange results. I know when I have explicitly enabled a lock
> on linux, I never have any idea when Windows has implicitly enabled one.
> 
> On the other hand, I've never understood why things like drag lock and
> middle button emulation were down in the low level driver. I think it would
> be wonderful to have stuff like this at a higher level, and even user
> scriptable so I could do things like reassign some of those silly extra
> unneeded "media" function keys they keep adding to keyboards to be mouse
> buttons instead (thus giving me a button I can push without making the mouse
> move even for a regular mouse, or giving me a 2nd and 3rd mouse button even
> for an Apple computer :-).

In X, you don't really have any choice, the two places to put it are the driver or the X server itself, and the path of least resistance is the driver. So this was originally implemented in the mouse driver and then reimplemented when evdev took over (2008-ish). You couldn't do this in the WM/toolkit in X because there was no guarantee you'd ever get the other button event (-> stuck buttons).

For a Wayland stack, this feature is best implemented in the compositor. Which would then also allow for extra features such as on-screen notifications when it engages, etc.

Comment 6 Tom Horsley 2015-08-03 10:20:20 UTC
>how are you holding the trackball?

I'm afraid this question makes no sense to me. It sits on the desk, I don't hold anything. Perhaps this gives you a better idea:

http://www.kensington.com/us/us/4493/k64325/expert-mouse#.Vb9AN3UVhBc

Comment 7 Peter Hutterer 2015-08-04 02:04:57 UTC
right, thanks. on the M570 the trackball is essentially a normal 3-button mouse with a ball on the left side where the thumb is. that makes the hand position obvious.
I take it the hand position on the Kensington is so that you operate the ball with the fingertips of your index/middle finger?

Comment 8 Tom Horsley 2015-08-04 17:04:23 UTC
(In reply to Peter Hutterer from comment #7)

> I take it the hand position on the Kensington is so that you operate the
> ball with the fingertips of your index/middle finger?

Right.

Comment 9 Peter Hutterer 2015-08-07 04:29:39 UTC
for reference, I've filed a GNOME bug as well.
https://bugzilla.gnome.org/show_bug.cgi?id=753341

Comment 10 Peter Hutterer 2015-08-11 05:53:52 UTC
give this one a try please. should work the same, but the property name is prefixed with 'libinput' instaed of Evdev

http://koji.fedoraproject.org/koji/taskinfo?taskID=10668406

Comment 11 Tom Horsley 2015-08-11 11:53:22 UTC
Doesn't seem to have any effect. I changed my xinit script to this:

xinput --set-button-map \
       'Kensington      Kensington Expert Mouse' \
       1 8 3 4 5 6 7 2
xinput --set-prop --type=int --format=8 \
       'Kensington      Kensington Expert Mouse' \
       'libinput Drag Lock Buttons' 2 1

If I run list-props I get:

xinput list-props 'Kensington      Kensington Expert Mouse'
Device 'Kensington      Kensington Expert Mouse':
	Device Enabled (151):	1
	Coordinate Transformation Matrix (153):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Accel Speed (283):	0.000000
	libinput Accel Speed Default (284):	0.000000
	libinput Natural Scrolling Enabled (285):	0
	libinput Natural Scrolling Enabled Default (286):	0
	libinput Send Events Modes Available (268):	1, 0
	libinput Send Events Mode Enabled (269):	0, 0
	libinput Send Events Mode Enabled Default (270):	0, 0
	libinput Left Handed Enabled (287):	0
	libinput Left Handed Enabled Default (288):	0
	libinput Scroll Methods Available (289):	0, 0, 1
	libinput Scroll Method Enabled (290):	0, 0, 0
	libinput Scroll Method Enabled Default (291):	0, 0, 0
	libinput Button Scrolling Button (292):	2
	libinput Button Scrolling Button Default (293):	274
	libinput Middle Emulation Enabled (294):	0
	libinput Middle Emulation Enabled Default (295):	0
	Device Node (271):	"/dev/input/event2"
	Device Product ID (272):	1149, 4128
	libinput Drag Lock Buttons (413):	2, 1

I'm pretty sure I installed the right rpm:

rpm -q xorg-x11-drv-libinput
xorg-x11-drv-libinput-0.13.0-1bz1249309.fc22.x86_64

but I get no drag lock behavior. If I run xev pressing the button just tells me I pressed and released button 8.

I'll attach my xorg log where it definitely says it is using libinput for the mouse driver.

Comment 12 Tom Horsley 2015-08-11 11:54:27 UTC
Created attachment 1061457 [details]
Xorg.0.log with new libinput X driver installed

Comment 13 Peter Hutterer 2015-08-12 00:09:44 UTC
hmm, indeed, there was a bug that was triggered by that specific configuration but not the one I tested. Let's try again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10675684

Comment 14 Tom Horsley 2015-08-12 00:39:24 UTC
I'm afraid it looks exactly the same, no drag lock, xev says I'm pressing and releasing button 8 when I click it. Same list-props output as above. I did have to dig up new libinput rpms from koji as well to make the dependencies happy. Here's what I installed:

libinput-devel-0.21.0-3.fc22.x86_64
libinput-0.21.0-3.fc22.x86_64
xorg-x11-drv-libinput-0.13.0-1bz1249309.fc22.x86_64

Comment 15 Peter Hutterer 2015-08-12 01:49:48 UTC
guess it would help to actually apply the patch too...
http://koji.fedoraproject.org/koji/taskinfo?taskID=10676259

this one definitely works here

Comment 16 Tom Horsley 2015-08-12 17:18:57 UTC
(In reply to Peter Hutterer from comment #15)
> guess it would help to actually apply the patch too...
> http://koji.fedoraproject.org/koji/taskinfo?taskID=10676259

Yes! That one does indeed work. I'm happily dragging around windows now using libinput. Thanks!

Comment 17 Fedora Update System 2015-08-16 22:55:33 UTC
xorg-x11-drv-libinput-0.13.0-2.fc23 has been submitted as an update for Fedora 23.
https://admin.fedoraproject.org/updates/xorg-x11-drv-libinput-0.13.0-2.fc23

Comment 18 Fedora Update System 2015-08-16 22:56:09 UTC
xorg-x11-drv-libinput-0.13.0-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/xorg-x11-drv-libinput-0.13.0-2.fc22

Comment 19 Fedora Update System 2015-08-19 08:20:15 UTC
Package xorg-x11-drv-libinput-0.13.0-2.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-libinput-0.13.0-2.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-13739/xorg-x11-drv-libinput-0.13.0-2.fc22
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2015-08-23 16:40:15 UTC
xorg-x11-drv-libinput-0.13.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-09-01 09:58:27 UTC
xorg-x11-drv-libinput-0.14.0-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-libinput'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14617

Comment 22 Fedora Update System 2015-09-18 20:51:50 UTC
xorg-x11-drv-libinput-0.14.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.