Bug 446780 - DragLockButtons option no longer works
Summary: DragLockButtons option no longer works
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-05-15 23:45 UTC by Tom Horsley
Modified: 2010-11-21 12:35 UTC (History)
3 users (show)

Fixed In Version: 2.1.0-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-21 06:21:52 UTC

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

System ID Priority Status Summary Last Updated
FreeDesktop.org 15961 None None None Never

Description Tom Horsley 2008-05-15 23:45:25 UTC
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 23:46:19 UTC
Created attachment 305559 [details]
The xorg.conf file

Comment 2 Tom Horsley 2008-05-15 23:47:31 UTC
Created attachment 305561 [details]
The X log file that doesn't work

Comment 3 Tom Horsley 2008-05-15 23:48:47 UTC
Created attachment 305562 [details]
The log from fedora 8 where it worked fine

Comment 4 Tom Horsley 2008-05-16 13:38:47 UTC
Just to be belt and suspenders, I reported this upstream as well:


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

(moving to xorg-x11-drv-evdev component)

Comment 6 Peter Hutterer 2008-11-21 06:21:52 UTC
evdev 2.1 has drag lock support

you can get a package from

Comment 7 Paul Elliott 2010-11-21 07:10:58 UTC
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 12:35:21 UTC
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.