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.
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 :-).
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
(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.
>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 :-).
(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.
>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
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?
(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.
for reference, I've filed a GNOME bug as well. https://bugzilla.gnome.org/show_bug.cgi?id=753341
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
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.
Created attachment 1061457 [details] Xorg.0.log with new libinput X driver installed
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
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
guess it would help to actually apply the patch too... http://koji.fedoraproject.org/koji/taskinfo?taskID=10676259 this one definitely works here
(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!
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
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
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).
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.
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
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.