Bug 524428 - drag lock mess
Summary: drag lock mess
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-20 03:12 UTC by Tom Horsley
Modified: 2018-04-11 15:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-02 04:55:46 UTC
Type: ---


Attachments (Terms of Use)
xorg.conf (4.82 KB, text/plain)
2009-11-01 22:00 UTC, Tom Horsley
no flags Details
Xorg.0.log (37.09 KB, text/plain)
2009-11-01 22:03 UTC, Tom Horsley
no flags Details
dmesg (45.82 KB, text/plain)
2009-11-01 22:04 UTC, Tom Horsley
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 24713 0 None None None Never

Description Tom Horsley 2009-09-20 03:12:13 UTC
Description of problem:

Perhaps this is just severe lack of documentation, or perhaps it is a
real bug, but when I try to set a drag lock button for use with my
kensington trackball, things get messed up beyond belief. The trackball
has 4 big buttons arranged around the ball showing these button numbers
in xev before I start trying to set draglock:

 2  8
 1  3

I try to turn button 8 into a drag lock for button 1 using this:

xinput set-prop \
       'Kensington      Kensington Expert Mouse' \
       'Evdev Drag Lock Buttons' 8 1

After running that command, I see the following behavior:

buttons 3 and 8 exhibit no change, they still report a press and release
in xev when I click them, so 8 didn't turn into a drag lock.

button 1 is now a drag lock for button 8, clicking it once reports
only a button 8 press, clicking it again reports a button 8 release.

meanwhile, button 2 is now a drag lock for button 1 (which sort of eliminates
the idea that the values are reversed in the command).

I tried several variations (like making 8 1 be a string '8 1' instead or
reversing them and passing 1 8), but nothing caused any remotely sensible
behavior, I got into strange and wondrous states every time.


Version-Release number of selected component (if applicable):
xorg-x11-drv-evdev-2.2.99-7.20090909.fc12.x86_64

How reproducible:
The strange behaviors seem very consistent if I run the same xinput command.

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
Wacked out button behavior.

Expected results:
A nice draglock button (without which a trackball is almost impossible
to use).

Additional info:

http://lists.freedesktop.org/archives/xorg/2009-September/047309.html

Maybe this mailing list thread will provide some insight?

Comment 1 Tom Horsley 2009-09-20 14:08:52 UTC
I also tried set-int-prop with args 8 8 1 and got identical behavior
to set-prop 8 1, so that makes it seem more likely to be a problem
in the driver somewhere, not in the xinput app.

Comment 2 Tom Horsley 2009-10-24 17:45:31 UTC
Just to add an update - I tried again with my newly installed and
update Fedora 12 Beta, and I see the same results.

I also tried just making button 8 be a "universal" drag lock, and it
works somewhat better, but still seems weird. The button sequence
click 8, click 1, does start a drag with button 1, but to stop the
drag, I have to click 8, click 1 again. I would have hoped that
just clicking 1 (or just clicking 8) by itself would stop the drag.

Comment 3 Tom Horsley 2009-10-24 18:07:08 UTC
I also added this upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=24713

Comment 4 Matěj Cepl 2009-11-01 21:44:57 UTC
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available), /var/log/dmesg, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 5 Tom Horsley 2009-11-01 22:00:22 UTC
Created attachment 367042 [details]
xorg.conf

This is the xorg.conf file I use in order to get draglock to work the old way
with evdev disabled. On a freshly installed f12 beta where I tried using xinput
to do the draglock, I had no xorg.conf file.

Comment 6 Tom Horsley 2009-11-01 22:03:16 UTC
Created attachment 367043 [details]
Xorg.0.log

Here's the Xorg.0.log file from the last time I booted the system (which means my
xorg.conf file was in place). If you want an Xorg.0.log with no xorg.conf, let
me know, and I'll rename xorg.conf and boot and try to play with xinput again.

Comment 7 Tom Horsley 2009-11-01 22:04:35 UTC
Created attachment 367044 [details]
dmesg

Here's the dmesg file, also from the last time I booted the system.

Comment 8 Peter Hutterer 2009-11-02 04:55:46 UTC
Thanks for reporting, bug is fixed in xorg-x11-drv-evdev-2.3.0-2.

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

Comment 9 Fedora Update System 2009-11-05 22:52:32 UTC
xorg-x11-drv-evdev-2.3.0-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.3.0-2.fc12


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