Bug 603953 - Left Mouse Key goes dead
Left Mouse Key goes dead
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
12
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-14 20:15 EDT by Richard Hitt
Modified: 2018-04-11 11:13 EDT (History)
3 users (show)

See Also:
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-22 22:33:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X server config file, /etc/X11/xorg.conf (849 bytes, text/plain)
2010-06-15 06:10 EDT, Richard Hitt
no flags Details
X server log files /var/log/Xorg.*.log (239.09 KB, text/plain)
2010-06-15 06:12 EDT, Richard Hitt
no flags Details
Output of the dmesg command (26.56 KB, text/plain)
2010-06-15 06:13 EDT, Richard Hitt
no flags Details
The system log file, /var/log/messages (42.82 KB, text/plain)
2010-06-15 06:13 EDT, Richard Hitt
no flags Details

  None (edit)
Description Richard Hitt 2010-06-14 20:15:30 EDT
Description of problem:
Left Mouse Key goes dead.  Other mouse keys work.  Restarting X, with Control-Alt-Backspace, cures the problem.

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

How reproducible:
Every time.

Steps to Reproduce:
1. Hit the zero key on the numeric keypad and then the right-arrow key on the main keyboard
2. Observe that the left mouse button no longer has any functionality whatsoever.
3. Hit Control-Alt-Backspace to restart X and observe Left Mouse button works fine.
4. Rinse and repeat.
  
Actual results:
see above

Expected results:
it shouldn't do that

Additional info:
This problem is observed both on my Dell Dimension 4700, with standard Dell keyboard, and my HP ze5250 laptop.  Both machines are kept up-to-date.

The failure occurs whether the "Num Lock" light on the Dell keyboard is on or off.

The failure occurs whether the two keys are hit in rapid succession or with a couple of seconds in between.

This problem seems to be a new problem; it seems to have started within the last month or more recently.  I encounter it when in using my right arrow key I clumsily bump into the key just to its right, the numeric-keypad "0/Ins" key.
Comment 1 Richard Hitt 2010-06-14 20:41:15 EDT
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.
Comment 2 Matěj Cepl 2010-06-15 05:16:08 EDT
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.
Comment 3 Richard Hitt 2010-06-15 06:10:58 EDT
Created attachment 424091 [details]
X server config file, /etc/X11/xorg.conf
Comment 4 Richard Hitt 2010-06-15 06:12:22 EDT
Created attachment 424092 [details]
X server log files /var/log/Xorg.*.log
Comment 5 Richard Hitt 2010-06-15 06:13:04 EDT
Created attachment 424093 [details]
Output of the dmesg command
Comment 6 Richard Hitt 2010-06-15 06:13:37 EDT
Created attachment 424094 [details]
The system log file, /var/log/messages
Comment 7 Richard Hitt 2010-06-15 06:20:20 EDT
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.
Comment 8 Richard Hitt 2010-06-16 18:19:50 EDT
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.
Comment 9 Peter Hutterer 2010-06-18 02:15:21 EDT
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?
Comment 10 Richard Hitt 2010-06-18 14:40:08 EDT
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.
Comment 11 Matěj Cepl 2010-06-20 08:06:10 EDT
(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.
Comment 12 Matěj Cepl 2010-06-20 08:07:11 EDT
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?
Comment 13 Matěj Cepl 2010-06-20 08:09:00 EDT
(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!
Comment 14 Richard Hitt 2010-06-22 16:43:34 EDT
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.
Comment 15 Andy Lawrence 2010-07-19 16:57:43 EDT
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.
Comment 16 Fedora Update System 2010-07-19 23:07:05 EDT
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
Comment 17 Fedora Update System 2010-07-22 22:33:35 EDT
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.

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