Bug 446780 - DragLockButtons option no longer works
DragLockButtons option no longer works
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-15 19:45 EDT by Tom Horsley
Modified: 2010-11-21 07:35 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.1.0-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-21 01:21:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The xorg.conf file (879 bytes, text/plain)
2008-05-15 19:46 EDT, Tom Horsley
no flags Details
The X log file that doesn't work (38.01 KB, text/plain)
2008-05-15 19:47 EDT, Tom Horsley
no flags Details
The log from fedora 8 where it worked fine (562.24 KB, text/plain)
2008-05-15 19:48 EDT, Tom Horsley
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 15961 None None None Never

  None (edit)
Description Tom Horsley 2008-05-15 19:45:25 EDT
Description of problem:

I have this input device section in my xorg.conf file which has always

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "Auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
        Option      "DragLockButtons" "2 1"

That sets up button 2 to act as a drag lock of button 1.
In the new fedora 9 version of X11 it no longer has any effect.
Button 2 still shows up as button 2, and I get no drag lock
(which makes a trackball virtually impossible to use).

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. add the DragLockButtons definition
2. restart X (or reboot - it is juat as ineffective)
3. get no drag lock
Actual results:

no drag lock

Expected results:

click button 2 to look like button 1 is held down

Additional info:

I'll attach the full xorg.conf as well as the log file showing
that X recognized the directive and claimed to setup the drag
lock. This same input device works great on fedora 8.
Comment 1 Tom Horsley 2008-05-15 19:46:19 EDT
Created attachment 305559 [details]
The xorg.conf file
Comment 2 Tom Horsley 2008-05-15 19:47:31 EDT
Created attachment 305561 [details]
The X log file that doesn't work
Comment 3 Tom Horsley 2008-05-15 19:48:47 EDT
Created attachment 305562 [details]
The log from fedora 8 where it worked fine
Comment 4 Tom Horsley 2008-05-16 09:38:47 EDT
Just to be belt and suspenders, I reported this upstream as well:

Comment 5 Peter Hutterer 2008-08-18 00:59:44 EDT
FYI, upstream just got drag lock support.

(moving to xorg-x11-drv-evdev component)
Comment 6 Peter Hutterer 2008-11-21 01:21:52 EST
evdev 2.1 has drag lock support

you can get a package from
Comment 7 Paul Elliott 2010-11-21 02:10:58 EST
To make draglocks work for my account under Fedora 13 I did the following

sudo yum install xinput

create a .xprofile file with the following content
xinput --set-int-prop 'ImExPS/2 Generic Explorer Mouse' 'Evdev Drag Lock Buttons' 8 8 1 9 3

chmod a+x .xprofile

Re login to the xserver.

Drag locks work perfectly.
Comment 8 Tom Horsley 2010-11-21 07:35:21 EST
Yea, draglock did finally make it into evdev and xinput, but it was first
disabled for quite some time because they made evdev the default before
providing all the features that the old input system previously had (an
all too common phenomenon :-).

But talk about underdocumented features, where the heck did ~/.xprofile
come from? I never heard of it.

In any case, I need to use this program:


which provides a hack for yet another missing feature: It re-runs the
xinput command to setup draglock when I plug the mouse back in after
unplugging it (which is what happens when I switch to a different
system with my KVM box).

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