Bug 603953
Summary: | Left Mouse Key goes dead | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Hitt <rbh00> | ||||||||||
Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | low | ||||||||||||
Version: | 12 | CC: | dr.diesel, mcepl, xgl-maint | ||||||||||
Target Milestone: | --- | Keywords: | Triaged | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i686 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | xorg-x11-server-1.8.2-2.fc13 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2010-07-23 02:33:40 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: |
|
Description
Richard Hitt
2010-06-15 00:15:30 UTC
I have determined that the Left Mouse functionality is restored by hitting the plus key of the numeric keyboard. But the problem remains in my opinion a serious bug. An accidental single keystroke should not have such a surprising, devastating effect. One can't be expected to try all the keys on the keyboard in an attempt to restore the functionality of an apparently unrelated Left Mouse button. I can confirm that it happens to my wife's F12 as well. Will add some logs when it happens again. Please add drm.debug=0x04 to the kernel command line, restart computer, wait until the issue happens, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance. Created attachment 424091 [details]
X server config file, /etc/X11/xorg.conf
Created attachment 424092 [details]
X server log files /var/log/Xorg.*.log
Created attachment 424093 [details]
Output of the dmesg command
Created attachment 424094 [details]
The system log file, /var/log/messages
All of those four attachments were taken after the problem described in this bugid was reproduced. For my convenience, the problem was reproduced on my HP laptop, not my Dell box; but it is the same problem and the level of Fedora 12 is the same. I should say that hitting the right-arrow key is not required for reproducing the problem; merely hitting the numeric-keypad "0/Ins" key causes the Left Mouse button to go dead (and seemingly the mouse movement to enter some kind of selection mode, which you will probably notice). Thanks very much for your unexpectedly quick response! If I can do anything else or any other tests for you, please let me know. I have used xev(1) to demonstrate the steps that cause the Left Mouse Button to become nonfunctional, and for it to become functional again. Here is a detailed recipe to reproduce the problem. 1. Set the Mouse Keys feature on: At System -> Preferences -> Keyboard, select tab "Mouse Keys" and observe the box "Pointer can be controlled using the keypad". If the box is not selected, do Alt-P and observe that it is selected. Click Alt-C to select "Close" and ENTER to close the window. 2. Type 'xev' and hit ENTER. A new window will open, with a smaller window inside it with a heavy border. Move the mouse pointer into the new window but outside of the smaller window. Now lift the mouse from the mouse pad to be able to click without causing mouse motion. 3. With the lifted mouse, click and release the left button. Observe that a ButtonPress event and a ButtonRelease event occur for button 1. 4. Hit the numeric-keypad key "0/Ins" exactly once. Observe that a ButtonPress event happens for button 1. 5. Hit the numeric-keypad key "./Del" exactly once. Observe that a ButtonRelease event happens for button 1. The above behavior is normal and correct. Now for the problem: 6. Hit the numeric-keypad key "0/Ins" exactly once. Observe that a ButtonPress event happens for button 1. 7. With the lifted mouse, click and release the left button. Observe that no event happens. EXPECT THAT ButtonRelease event would happen. 8. Hit the numeric-keypad key "./Del" exactly once. Observe that no event happens. EXPECT THAT ButtonRelease event would happen. 9. With the lifted mouse, click and release the left button. Observe that nothing at all happens. 10. Hit the numeric-keypad key "./Del". Hit it again. Hit it again. Keep hitting it. Notice that no events happen. The above behavior is incorrect. Probably at step 7 a ButtonRelease event should happen. If not then, at the very least the "./Del" key at step 8 should cause a ButtonRelease event. With the mouse and keyboard in this state, perform the following two steps to restore normality: 11. Hit the numeric-keypad key "0/Ins" once. Notice that no event happens. 12. Hit the numeric-key-ad key "./Del" once. Observe that a ButtonRelease event happens for button 1. Now the mouse left button should be back to its normal behavior, as in step 3 above. I can't reproduce this on F-13. I'm pretty sure this is the upstream commit xkb: Post PointerKeys through the XTEST device. that fixed it, but I'm not sure and the time for backporting this is a bit limited. Do you have a chance to test if that's still an issue on F-13? Hi, Peter. I tested your hunch in two ways, and both tests confirm that the problem I reported is fixed, but both show up another nasty problem: selection via combined numeric keypad and actual mouse works wrong. Specifically, "0/Ins" and then any mouse movement moves the pointer instantly to the bottom right of the physical screen. But selection purely by mouse works correctly. And selection purely by keypad doesn't cause the pointer to take this mindboggling leap but seems to report too many events. The Operating System I used for the following cookbook was the Fedora 13 Live CD, with iso filesize 707788800 and sha256sum: 47ccc37db256387b70857f53a6067e8d50e692c9aa85e45e63e5190c5d1e0942 Fedora-13-i686-Live.iso To reproduce the new problem: 1. Set the Mouse Keys feature on: At System -> Preferences -> Keyboard, select tab "Mouse Keys" and observe the box "Pointer can be controlled using the keypad". If the box is not selected, do Alt-P and observe that it is selected. Click Alt-C to select "Close" and ENTER to close the window. 2. Type 'xev' and hit ENTER. A new window will open, with a smaller window inside it with a heavy border. Move the mouse pointer into the new window but outside of the smaller window. Leave the mouse on its mouse pad. 3. Hit the numeric-keypad key "0/Ins" exactly once. Observe that a ButtonPress event happens for button 1. 4. Move the mouse the slightest little bit on its pad. Observe that the pointer immediately moves to the lower right spot on the screen (resulting in "root:(1023, 767)" on the laptop where I conducted my tests). EXPECT THAT the screen position should change by only a little bit. In fact, a typical one of my tests of this step yielded these events: ButtonPress LeaveNotify MotionNotify seven more MotionNotify events with different timestamps The LeaveNotify and the MotionNotifys all reported "root:(1023,767)" and the ButtonPress reported "root:(116,142)". To show that only the combination of keypad-and-mouse fails: 5. Instead of 4. above, type the numeric-keypad "1" key. Observe that the MotionNotify event properly shows an x decrease by 1 and a y increase by 1. 6. Instead of 3. and 4. above, Press and Hold the Left Mouse Button; observe ButtonPress; move the Mouse a tiny amount; notice that successive MotionNotify events show proper changes in the position of the pointer. Release, and observe ButtonRelease. I see another potential problem as well. At step 6 above, I see only ButtonPress event, multiple MotionNotify events, and ButtonRelease event. But at step 5 above, doing the same sort of operation but using the numeric keypad exclusively, I see ButtonPress event and then for each keystroke "numeric-keypad 1" I see three events: MotionNotify MotionNotify KeyRelease The two MotionNotify events that occur for each "numeric-keypad 1" press and release show exactly the same information. This seems like it deserves a separate bug report, since it's a separate symptom and occurs on a different Fedora release. Tell me what you'd like me to do, and I'll do it. Thanks for your quick analysis of my original bug report. (In reply to comment #9) > I can't reproduce this on F-13. > > I'm pretty sure this is the upstream commit > xkb: Post PointerKeys through the XTEST device. > that fixed it, but I'm not sure and the time for backporting this is a bit > limited. Do you have a chance to test if that's still an issue on F-13? So, yes, I can fully reproduce this with F12 and [root@narcis yum.repos.d]# rpm -qa \*xkb\* \*Xorg\* xorg-x11-xkb-utils-7.4-6.fc12.i686 libxkbfile-1.0.6-1.1.fc12.i686 xorg-x11-server-Xorg-1.7.6-4.fc12.i686 and switched on Mouse Keys option. Given that this breaks accessibility stuff and it seems that you have an idea how to fix this, could I plead for this being fixed in F-12 as well? (In reply to comment #10) > This seems like it deserves a separate bug report, since it's a > separate symptom and occurs on a different Fedora release. Tell me > what you'd like me to do, and I'll do it. Thanks for your quick > analysis of my original bug report. Yes, please. You are totally right that this is another bug (and as bad as the original one) we should fix it in F13 as well, and given my comment 12 I would like this bug not to slide in fixing your later finding. Thank you for a huge help! Hi, Matej! Okay, bugid 606978 added. It refers to this bugid's Comment 10 and also includes that comment's text as an attachment. I have also tested the general operation of physical and mousekey operations on F10 and F7, and if it would be helpful to you to have a write-up of the results, I'll write something up. The short of it is that F7 appears to work completely correctly, but F10 does not; yet F10 does not show either of these bugs 603953 or 606978. Looks like this has been identified but I can confirm this is happening on two F13_64 bit boxes. libxkbfile-1.0.6-2.fc13.x86_64 xorg-x11-server-Xorg-1.8.2-1.fc13.x86_64 libxkbfile-devel-1.0.6-2.fc13.x86_64 xorg-x11-xkb-utils-7.4-7.fc13.x86_64 I can post logs if requested. xorg-x11-server-1.8.2-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.2-2.fc13 xorg-x11-server-1.8.2-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |