Touch screen and touchpad lost click function after quickly tapped dash home repeatly by touch screen

[Tim Chen]

Touch screen and touchpad lost click function after quickly tapped dash home repeatly by touch screen, Installed 14.04, still have same issue.

Quickly tapped dash home more than three times by touch screen.Found touch screen and touchpad lost click function.

Note:
1.When this issue occured, cursor still can be moved by touch screen/touchpad.
2.When this issue occured ,click/double click by touch screen/touchpad,left click/right click by touchpad all were not workable.

Steps to Reproduce:
1.install 12.04.4 image or 14.04 image, boot into Ubuntu OS.
2.Quickly tapped dash home more than three times by touch screen.
3.Found touch screen and touchpad lost click function.

This bug is reported from private OEM project, also check https://launchpad.net/bugs/1297067

======

using xinput --query-state can actually see the button press event

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ syntp id=6 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=11 [slave pointer (2)]

#xinput --query-state 11
2 classes :
ButtonClass
 button[1]=up
 button[2]=up
 button[3]=up
 button[4]=up
 button[5]=up
ValuatorClass Mode=Absolute Proximity=In
 valuator[0]=398
 valuator[1]=1652
 valuator[2]=5
 valuator[3]=3
 valuator[4]=0
 valuator[5]=399
 valuator[6]=1653

#xinput --query-state 6
2 classes :
ButtonClass
 button[1]=down
 button[2]=up
 button[3]=up
 button[4]=up
 button[5]=up
 button[6]=up
 button[7]=up
 button[8]=up
ValuatorClass Mode=Relative Proximity=In
 valuator[0]=1
 valuator[1]=394

touchpad's button and touchpanel's
valuator[2] and valuator[3] will changed after we press the button (or monitor)

Also I found press "super" on keyboard will recover the touchscreen/touchpad loss.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.20.0-0ubuntu3
ProcVersionSignature: Ubuntu 3.11.0-18.32~precise1-generic 3.11.10.4
Uname: Linux 3.11.0-18-generic x86_64
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: amd64
CompizPlugins: [core,commands,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
Date: Mon Apr 21 16:50:04 2014
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-stella-daan2-precise-amd64-20140416-1
InstallationMedia: Ubuntu 12.04 "Precise" - Failed to find casper uuid.conf in 'binary/casper/initrd.img-3.11.0-18-generic.old-dkms' LIVE Binary 20140416-06:52
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ara Pulido (ara)]

Stephen, can you assign someone to this bug, please?

We will need it fixed in Trusty at least.

[Kai-Heng Feng (kaihengfeng)]

This bug can be reproduced using evemu-tools.

I recorded an event sequence which can introduced the bug (but not all the time):

$ sudo apt-get install evemu-tools

$ sudo evemu-device s.prop

this will create a new device /dev/input/event# (# is the number showed in the terminal)

$ sudo evemu-play /dev/input/event# < s.event

Expect behavior: nothing happens.

Actually behavior: Touchscreen/Trackpad/Mouse cursor works fine, but it can no longer clicks.
press keyboard Alt+Tab can make click work again.

[Stephen M. Webb (bregma)]

I sometimes see the following warning appear in $HOME/.cache/upstart/gnome-session-Unity.log when rapidly tapping in the Dash.

WARN 2014-05-05 11:18:50 nux.geisadapter GeisAdapter.cpp:157 Failed to dispatch events! Status: 20

[Stephen M. Webb (bregma)]

Another observation: I could not obtain the described symptoms unless I had an application open (eg. the Terminal). This is true even when using the attached evemu captures.

It's possible this bug is related to #1307701.

[Eleni Maria Stea (hikiko)]

Some additional observations:

I usually reproduce this bug on my desktop pc that doesnt have a touchpad/trackball (mouse only) by moving the cursor inside the launcher area while this command from comment #3 is executed:
$ sudo evemu-play /dev/input/event# < s.event
(the comment: https://bugs.launchpad.net/oem-priority/+bug/1310518/comments/3)

i.imgur.com/rtXckuE.jpg
In the screenshot above I got the bug while I was switching workspaces and in this case alt+tab doesn't restore the mouse click.

[Eleni Maria Stea (hikiko)]

My findings about this bug, so far:
The problem is that there's a mouse grab by compiz at some point, that is caused by the XGrabButton call in updatePassiveButtonGrabs in window.cpp:
[...]
 else
 {
 /* Grab all buttons */
        XGrabButton (screen->dpy (),
             AnyButton,
             AnyModifier,
      serverFrame, false,
      ButtonPressMask | ButtonReleaseMask | ButtonMotionMask,
             GrabModeSync,
      GrabModeAsync,
      None,
             None);
[...]

(I verified that this by replacing the default mouse pointer shape with the XC_pirate: when the bug occured the pointer changed to a pirate head.)

This grab is used by compiz for windows that don't have the focus: when the user clicks inside a window, compiz grabs the mouse so that the mouse events are handled by compiz and not by the window. That's useful in case someone needs to raise a window by clicking on it as opposed to clicking on its frame for example.

The XGrabButton uses the GrabModeSync. According to the XGrabPointer manpage:
if the pointer mode is GrabModeSync the state of the pointer, as seen by client applications, appears to freeze, and the X server generates no further pointer events until the grabbing client calls XAllowEvents or until the pointer grab is released. Actual pointer changes are not lost while the pointer is frozen; they are simply queued in the server for later processing.

(that's why we can't click anywhere after this grab occurs)

I believe that a race condition related to the grabs/ungrabs is triggered here and it's difficult to be found because the passive grab is initiated by the xserver when the conditions set by the XGrabButton call are satisfied, so backtraces are not really helpful.

[Ara Pulido (ara)]

Tim, is this still happening? I cannot reproduce it in Trusty

[Jerry Kao (jerry.kao)]

Can not reproduce this issue in Trusty with Unity 7.2.4

[Will Cooke (willcooke)]

Can't reproduce. Marking as incomplete. If this is still an issue please comment and we can target for X.

[Launchpad Janitor (janitor)]

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for unity (Ubuntu Xenial) because there has been no activity for 60 days.]