Bug 524428
| Summary: | drag lock mess | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Horsley <horsley1953> | ||||||||
| Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> | ||||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | rawhide | CC: | mcepl, xgl-maint | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-11-02 04:55:46 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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. 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. I also added this upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=24713 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. 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.
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.
Created attachment 367044 [details]
dmesg
Here's the dmesg file, also from the last time I booted the system.
Thanks for reporting, bug is fixed in xorg-x11-drv-evdev-2.3.0-2. http://koji.fedoraproject.org/koji/taskinfo?taskID=1781900 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 |
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?