button1 gets stuck after a while

[Timo Aaltonen]

distro bug 1015183

after using the tablet for a while, the touchscreen fails to register button clicks anymore, since the "button" appears to be stuck "down".

[Timo Aaltonen (tjaalton)]

there's a thread on xorg-devel@ about turning off support for multitouch by default, and the discussion led to the main input developer reproducing the issue himself. We might have a patch early next week.

[Timo Aaltonen (tjaalton)]

..it's a bug in the xserver.

[Chris Wayne (cwayne)]

Note this is easy to reproduce after running xrotate

[Timo Aaltonen (tjaalton)]

My findings show that it's trivial to reproduce with unity by opening menus quickly (indicator menus for instance). Can't reproduce it with plain metacity. One way to mitigate the issue is to use the gui in a more "relaxed" manner :) That should make it harder to hit the race condition with input grabs.

and the issue seen after using xrotate to switch to portrait mode is something else (cursor jumping here and there), since it works fine after rotating back to landscape.

[Jani Monoses (jani)]

lilstevie on #ubuntu-arm says they saw the same behaviour on the Transformer Prime when running Unity.

[Timo Aaltonen (tjaalton)]

I'm able to "lock up" the Unity session by opening menus quickly by using a touchscreen. Seems as if there's a grab active. I can see the tooltips from launcher icons, interact with focused apps, but that's it.

Can't reproduce with plain metacity, because the menus open so quickly with it, whereas with Unity on this hw the effects slow it down so that the race is hit.

Tried several of the recent patches on top of 1.13, but they haven't helped. Now I see there are newer patches available. I'll give them a try. Filed this one for tracking this particular issue.

[Timo Aaltonen (tjaalton)]

tried patches from 56558 and 55738, also "Sync TouchListener memory.." from Carlos Garnacho, didn't help.

[Daniel d'Andrada (dandrader)]

I'm able to reproduce the issue in a reasonably reliable manner on a Dell XPS L502X laptop (it has a touchscreen) by rapidly tapping on the indicators in the top right corner of the screen.

[Daniel d'Andrada (dandrader)]

I just repeatedly tap on the top-most icon (the one which has the Ubuntu logo) of Ubuntu's launcher in a touchscreen. Those taps alternately open and close the dash (a fullscreen window that shows icons for applications, media and other files). Eventually those taps stop having any effect. I.e., the launcher no longer gets ButtonPress and ButtonRelease events out of them.

I've added a wealth of logging (see xorg.log attachment) to try to understand what's happening on the server. From looking at it could see the following:
From touches 2 to 26, launcher is the first window in the list of listeners. From touch 27 onwards, the root window is the first one. Problem is, from touch 27 onwards, xserver fails to pass the touch ownership down to the launcher window because there's always an older pointer-emulated touch (touch 26) lying around which it apparently can't get rid of (i.e. properly process).

[Daniel d'Andrada (dandrader)]

Created attachment 70064
log output of the "repeated tapping on ubuntu logo launcher icon" use case

[Peter Hutterer (peter-hutterer)]

Do cross-check with Bug 56557 as well, this can cause issues if any grabs are activated on the root window and I wonder if that influences the behaviour here

[Brendan Donegan (brendan-donegan)]

Hi Daniel,

Don't use In Progress to mean you are trying to reproduce the bug, only if you are actually working on fixing it.

[Daniel d'Andrada (dandrader)]

I was actually working on fixing it, but a couple of days ago I've moved to work on something else. Thus the status change.

[Brendan Donegan (brendan-donegan)]

Sorry if the above comment seemed rather blunt - I was only trying to discover if you've changed the status to Confirmed because you're no longer working on it? If you are still working on it then it should remain at 'In Progress' - and thanks either way :) !

[Victor Tuson Palau (vtuson)]

Assigning to the Desktop team as Daniel is being move to work on something else

[Daniel d'Andrada (dandrader)]

(In reply to comment #4)
> Do cross-check with Bug 56557 as well, this can cause issues if any grabs
> are activated on the root window and I wonder if that influences the
> behaviour here

Yes, they are at least closely related (most likely have the same cause) as a pointer-emulated touch gets "stuck" because of failed resource lookups in RetrieveTouchDeliveryData() as well.

[Daniel d'Andrada (dandrader)]

Created attachment 70422
log output of use case with patches from bug 56557 applied

With the 4 patches mentioned in bug 56557 applied (comments 3 and 4), the bug (missing ButtonPress and ButtonRelease events) manifests itself already on the second tap on the touchscreen.

Again, due to a failure in RetrieveTouchDeliveryData()

[Peter Hutterer (peter-hutterer)]

New set of patches, please try those on top of the current set you already tested.

http://patchwork.freedesktop.org/patch/12519/
http://patchwork.freedesktop.org/patch/12520/
http://patchwork.freedesktop.org/patch/12521/
http://patchwork.freedesktop.org/patch/12522/

[Daniel d'Andrada (dandrader)]

Created attachment 70656
log output of use case with patches from Comment 7 also applied

This is the log output I get with this new set of patches (from Comment 7) applied on top of those mentioned in Comment 6.

Again, the same problem.

The first tap on the icon with the ubuntu logo in the launcher (top left corner of the screen) works fine and displays the dash (a fullscreen window showing application icons, etc). The launcher now has a active pointer grab.

Upon the second tap on the ubuntu icon, xserver fails to deliver events to that listener (laucnher's active pointer grab) because the corresponding RetrieveTouchDeliveryData() call fails. A snippet from the log:

"""
(II) TouchBeginDDXTouch: ddx id 0, touch 2 - returning with emulate pointer == 1
[ 2859.473] (II) ProcessTouchEvent: TouchBegin, master pointer, touch 2
 ...
[ 2859.474] (II) RetrieveTouchDeliveryData: listener(window=launcher, listener=1105199104, type=pointer_grab, state=begin, level=core)
[ 2859.474] (II) dixLookupClient: failed! - rid & SERVER_BIT
[ 2859.474] (II) - Not delivering to listener 1105199104 because his delivery data couldn't be retrieved.
"""

[silentrunner (silentrunner)]

Is there a way to reset or free this lock via command line, so you do not have to log out/restart.
One could use this as a "snippet" for onboard since this seems to work during that condition.

[Oliver Grawert (ogra)]

sadly no, once it is stuck, it is stuck

[silentrunner (silentrunner)]

you probably thought everything through, but i can't help to ask. would it help as a temporary solution to disable multitouch and allow single touch input only. Then distinguishing only between single click (long as right click) and dragging.

[Jrand (jrand)]

We are also experiencing this bug with other touch screen software, not Unity related. The underlying X problem seems to be identical. Has a solution been found?

[Carsten Haitzler (raster-rasterman)]

I can reproduce this bug with 100% reliability in E17.

http://www.enlightenment.org/p.php?p=download

well ok - i'm using svn development, but i think last release (0.17.1 and efl 1.7.5) should produce the bug too as i noticed this issue just before 0.17 release too. install that (sorry source - there are ppa's but i dont know if there's an arm build. i compiled). i also have set up my n7 to run in portrait mode by default (~/.xsession sets it up).

now its installed, select enlightenment as your desktop (u may have to ln -s enlightenment.desktop from /usr/local/share/xsessions if u compiled into /usr/share/xsessions). go through the wizard and choose "mobile" profile. you pretty much can ignore everything except the small white arrow pointing down on the top-0left once the wizard is done...

DONT TOUCH that arrow... yet. notice u can click on most things and they work... now press that top-left arrow. its the "start button"... up comes a start menu... u can interact with it... and after that... clicks cease to work. this is 100% reliably reproduces on my nexus7/... it ALSO happens on my exopc too. so this is a general issue with xorg/xinput etc.

anyway - now i've spent some time digging into what's going on, and here's the low-down. wm's use passive button grabs (XGrabButton) for focus handling. they then do an XAllowEvents to allow the button grab to proceed to a child. after some sequence of mouse grabbing is done by popping up that menu, XAllowEvents ceases to ever work again (it never forwards a held button press event ever agin) for the duration of the xserver lifetime. i wrote a "test case" (attached) to show that the parent gets the events, simply calls xallowevents and it never goes to the child window ever again. this test client works fine until the "bug is triggered" then fails. (i shut down the wm but kept x alive and ran the test client to "prove this" - it works fine until the bug is triggered). unfortunately at this point i have yet to make a simple "trigger the bug" client, BUT i am sure it has something to do with a combination of:

1. button press handled after an xallowevents allowed it through
2. an xgrabpointer (unlikely an xgrabkeyboard).
3. some combination of user events (eg mouse/finger not being releases while the above allowevents and grab is going on).

after this "magic sequence" which also likely is race-condition sensitive, the xservers internal input handling is "busted" and xallowevents are broken until an xserver restart (restarting wm doesn't fix it - nor does totally killing the wm and bringing up test clients in its place as above).

so i'll have to say "sorry" in that i'm going to waste some peoples time by only having "more info" without a simple "reproduction case" in a simple contained src blob. i'd hope to have that, but currently don't. what i DO have is a 100% reliable "big fat bulky" reproduction case (e17+efl) AND... i have a simple test client to prove/show what the "stuck" thing is (allowevents of button press fails forever after triggering of the bug). given some more time/weekends i might be able to make such a client. the above was a saturday spent hunting for "what on earth is wrong", so...

[Timo Aaltonen (tjaalton)]

Nope, the bug is still there. Rasterman reproduced it with E17 and commented on the downstream bug:

https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994/comments/24

[Peter Hutterer (peter-hutterer)]

can you test this branch here please? http://cgit.freedesktop.org/~whot/xserver/log/?h=touch-grab-race-condition-56578

Last 5 commits (currently), starting with 2cd9c4f709f105b7a7faf31b8c10993d0949563c

[Timo Aaltonen (tjaalton)]

please test the xserver from this ppa once it's built, it has a few proposed fixes merged from the upstream bug:

https://launchpad.net/~ubuntu-nexus7/+archive/ppa

[Patola (patola)]

It failed:

 Build status

[image: [FAILEDTOBUILD]] Failed to build on
hamsa<https://launchpad.net/builders/hamsa>

   - Started 18 minutes ago
   - Finished 11 minutes ago (took 7 minutes, 43.4 seconds)
   - buildlog<https://launchpad.net/%7Eubuntu-nexus7/+archive/ppa/+build/4300026/+files/buildlog_ubuntu-raring-armhf.xorg-server_2%3A1.13.2-0ubuntu2.1_FAILEDTOBUILD.txt.gz>(16.2
KiB)

On Thu, Feb 14, 2013 at 3:58 AM, Timo Aaltonen <email address hidden> wrote:

> please test the xserver from this ppa once it's built, it has a few
> proposed fixes merged from the upstream bug:
>
> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
>
> ** Changed in: ubuntu-nexus7
> Status: Confirmed => Incomplete
>
> ** Changed in: ubuntu-nexus7
> Assignee: Canonical X.org (canonical-x) => Timo Aaltonen (tjaalton)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068994
>
> Title:
> button1 gets stuck after a while
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994/+subscriptions
>

--
Cláudio "Patola" Sampaio
IRC: ptl - Yahoo: patolaaa
Campinas, SP - Brazil.

[Timo Aaltonen (tjaalton)]

bah, messed up with the patch, will fix it soon

[Timo Aaltonen (tjaalton)]

unfortunately still able to reproduce it :/

I needed these commits on top of 1.13.2 to be able to compile with the new patches:
cc79107a5b60d2926e16ddbee04149e8d5acc969
fe59774c55e5d423633405e0869c22f4ce382548
91ab237358c6e33da854914d3de493a9cbea7637
9ad0fdb135a1c336771aee1f6eab75a6ad874aff

[Timo Aaltonen (tjaalton)]

new build is there, but I was able to test it myself and it's still broken.

[Patola (patola)]

On Thu, Feb 14, 2013 at 11:19 AM, Timo Aaltonen <email address hidden> wrote:

> new build is there, but I was able to test it myself and it's still
> broken.
>

Same here. However, it really seemed that the bug took longer than usual to
appear.

Should I keep this repository "just in case" (the bug will be solved on it
first, I suppose) or it might wreck my Ubuntu anytime?
--
Cláudio "Patola" Sampaio
IRC: ptl - Yahoo: patolaaa
Campinas, SP - Brazil.

[Peter Hutterer (peter-hutterer)]

You'll need all of http://cgit.freedesktop.org/~whot/xserver/log/?h=server-1.13-branch, at the least. I haven't tested this on 1.13.x at all, purely working from git master for now.

[Peter Hutterer (peter-hutterer)]

Sorry, to clarify: you need that 1.13 branch linked above AND the patches from Comment 11

[Timo Aaltonen (tjaalton)]

Created attachment 74845
evemu-record from the touchscreen

attached the evemu dump from reproducing the bug by hitting the unity indicators quickly a couple of times.

I'll try the more complete 1.13 build next.

[Timo Aaltonen (tjaalton)]

Patola: shouldn't wreck, but maybe disable to be safe.

Carsten: I built e17 0.17.1 and libs 1.7.5 from this ppa: https://launchpad.net/~efl/+archive/trunk/+packages
and couldn't reproduce the bug with xserver 1.13.99.901. Is the e17 release fresh enough? It did have the mobile profile to select, so guess it support touch..

[Timo Aaltonen (tjaalton)]

also, I have the deb's built for raring armhf here if someone wants to try reproduce the bug with them:

http://people.canonical.com/~tjaalton/e17-deb/

[Patola (patola)]

Is this bug still going to be worked on? It was a surprise to see that Ubuntu "phablet" did not use X. Is this why this bug has not been resolved yet? What is the status of "complete Ubuntu under Nexus 7" vs. "Ubuntu Phablet under Nexus 7"?

[Timo Aaltonen (tjaalton)]

upstream has a testcase for this now, should get fixed within the next week..

[Peter Hutterer (peter-hutterer)]

Ok, analysis of the bug as follows. To trigger this bug, we need the following client stack:
* touch client with a passive touch grab
* core client with a passive button grab in GrabmodeSync
* optional: core client with button mask on window
The touch client must reject the touch.

As the touch grab activates, all events are sent to the touch client, and stored in the touch event history. When the client rejects, the events are replayed on the next client.

The replayed TouchBegin will trigger the core passive grab, and switch the device's processInputProc to EnqueueEvent().
BUG 1: because touch event history replaying calls DeliverTouchEvents directly, EnqueueEvent is side-stepped and no events end up in the sync'd queue. Later, when the client calls XAllowEvents no events are there for syncing, ComputeFreezes() exits early and the emulated motion/release events are not sent to the client.

Fixing that is possible so that EnqueueEvent is honoured. Tricky though, because it will have a number of side-effects, see below.

BUG 2: because the TouchEnd never ends up in the history (by design) no release event ends up in the queue. So when replaying, the emulated button release is missing. Not sure yet how to fix this.

BUG3: If there's the optional third client, it's implicit passive grab currently does not get released. That's the easiest one to fix.

Side effects of the first bug:
If we use EnqueueEvent() for event history replaying, we will replay touch events into the sync buffer, but not actually process them. If there is at least one touch client below the client with the sync passive core grab, it cannot get touch events until the grabbing client calls XAllowEvents. If that touch client has the ownership mask set, that behaviour is against the protocol spec.

Coincidentally, this bug already exists anyway, it's just gone unnoticed so far because touch clients appear to be generally above the normal clients.

To be compliant with the touch specs, we need to wrap EnqueueEvent to still handle touch events for clients with the ownership mask even if the device is currently synced.

[Maarten Lankhorst (mlankhorst)]

grab http://people.canonical.com/~mlankhorst/xorg-server_1.14.1.orig.tar.gz
and xorg-server_1.14.1-0ubuntu0.3+1.15rc1+touch.diff.gz

[John Faulkner (johnnyuk)]

(In reply to comment #90)

Thank you, Maarten. I can patch and compile that copy but for some reason I'm getting a compilation error with the de12ce91d8e44ab9398e730b457e5abc8d1acbe6 branch in /dix/window.c line 421-425:

> REGION_INIT(pScreen, &pWin->clipList, &box, 1);
> REGION_INIT(pScreen, &pWin->winSize, &box, 1);
> REGION_INIT(pScreen, &pWin->borderSize, &box, 1);
> REGION_INIT(pScreen, &pWin->borderClip, &box, 1);

> window.c:421:5: error: the comparison will always evaluate as ‘true’ for the
> address of ‘box’ will never be NULL [-Werror=address]

Any ideas?

[Peter Hutterer (peter-hutterer)]

sorry guys, please take the compilation errors to the list. This bug is confusing enough with >90 comments and I'd like to keep off-topic stuff to a minimum.

pushed a new version of the branch after fixing a cursor refcounting issue that crashed my server when dragging and email in thunderbird. new branch tip is 9a5ad65330693b3273972b63d10f2907d9ab954a. This one also includes the fix Daniel wrote originally to avoid stuck buttons (http://lists.x.org/archives/xorg-devel/2013-April/035878.html)

[Maarten Lankhorst (mlankhorst)]

That fixed up the background corruptions and hangs on armhf/nexus 7, but I'm still seeing a stuck mouse button, and [ 77305.765] [Xi] Virtual core pointer: Failed to get event 8 for touchpoint 1.

[Maarten Lankhorst (mlankhorst)]

nm, bg is still corrupt when running in valgrind :(

[Peter Hutterer (peter-hutterer)]

fwiw, the latest branch got merged into master. It's still buggy but an improvement over the previous state.

commit c76a1b343d6a56aa9529e87f0eda8d61355d562b
Merge: 891123c 9a5ad65
Author: Keith Packard <email address hidden>
Date: Thu May 23 19:58:36 2013 -0600

    Merge remote-tracking branch 'whot/touch-grab-race-condition-56578-v3'

[Dsd-o (dsd-o)]

Thanks for all your work on this. At OLPC we've been testing the branch but have been a couple of commits behind the tip. Anyway, I think its still worth contributing the test result: no problems seen.

[Jrenyard (jrenyard)]

I would like to be any help I can with this bug fix. I am able to test on an 18.5" Winmate M185D as well as a 10" Winmate device (W10ID3S-PCH1). I am currently running Unity 13.04 and can make any necessary changes to the system. Please let me know what I can do to test and how to do it. I feel a bit over my head, but am willing to learn in order to be helpful.

[SunnyDrake (beebop)]

suffering from same issue :(
my tablet x86 tested distros
android-x86 - all ok
bodhi 2.3 - E17 same issue, after theme choose lc not works
ubuntu
-- unity mouse0 hang after 1-4 clicks
-- awn (Avant Window Navigator if im not mistaken) ... strange but no hungs .. just works
-- netbook-remix some controls works, some not (Qt framework issues?)
plasma active (KDE+Qt)
-- kubuntu .. not working, some icons can be clicked(+right sidebar rotates and drags) but dragging down main menu fails
-- basyskom-plasma-active-three-wetab-exopc-tablet-mer-relase.iso ( distro based on meego,mer,zypper) all works, uses Xorg 1.10

[James M. Leddy (jm-leddy)]

This change looks pretty big, is there any chance that we can SRU this for precise? The reason I ask is because it's a LTS release and we have a fair amount of hardware that is failing here: http://patchwork.freedesktop.org/patch/13650/

[Cody Swanson (codyswanson4)]

Wondering if anything has been happening in a while...

[Dsd-o (dsd-o)]

Peter fixed a load of stuff and it got merged in xserver master. Unfortunately there have not been any development releases of xserver master since that happened, but that will come in time.

If you are still seeing problems, and are definitely using xserver master, then I suggest explaining your problem here (if you are sure that you are seeing the same issue), or opening a new bug report (if it seems like your issue might be unrelated).

[Maarten Lankhorst (mlankhorst)]

The fix for bug #66720 looks relevant, commit 8eeaa74bc241acb41f1d upstream, it seems something broke for me though, so I can't test it right now.

[Maarten Lankhorst (mlankhorst)]

Nope, and I noticed a BUG on !pGrab in FreeGrab, I'll try it a bit more on monday.

[Cody Swanson (codyswanson4)]

(In reply to comment #99)
> Peter fixed a load of stuff and it got merged in xserver master.
> Unfortunately there have not been any development releases of xserver master
> since that happened, but that will come in time.
>
> If you are still seeing problems, and are definitely using xserver master,
> then I suggest explaining your problem here (if you are sure that you are
> seeing the same issue), or opening a new bug report (if it seems like your
> issue might be unrelated).

Thanks for the sumary! I was just wondering. Thanks!

[Peter Hutterer (peter-hutterer)]

(In reply to comment #101)
> Nope, and I noticed a BUG on !pGrab in FreeGrab, I'll try it a bit more on
> monday.

merged as 0e3be0b25fcfeff386bad132526352c2e45f1932 yesterday.

as for the rest, I really need something that's reproducible.

[inashdeen (inashdeen)]

I am quite new to ubuntu. How do i apply the patch to my system?

[Maarten Lankhorst (mlankhorst)]

I think the changes to onboard to use xinput2 directly may have fixed the remaining issue I was having. When I checked out onboard from trunk and used it on my nexus7 things worked, and nothing got stuck.

[Till Kamppeter (till-kamppeter)]

Maarten, I have checked with the new onboard ("bzr branch lp:onboard") now on an up-to-date Saucy with xserver packages from the x-staging PPA and I do not get a stuck-mouse-button effect any more.

[Glenn Watson (gw-c)]

What are the steps to test this regarding the two comments above? I'm assuming:

1) Download and flash the latest saucy preinstalled image.
2) Add the x-staging PPA and do an update/upgrade.
3) Use the newest onboard <--- How do I do this?

[Till Kamppeter (till-kamppeter)]

I did further testing over longer time and no stuck button. Its seems that with the current X from the x-staging PPA and the current Onboard from the onboard PPA the problem is solved.

[Peter Hutterer (peter-hutterer)]

Thanks for testing. I'm going to close this one as fixed since we definitely fixed quite a few bugs in this patch set. If there's something left please file a new bug so we can narrow down the new (old? :) issues.

[Till Kamppeter (till-kamppeter)]

This is fixed in the X version in the x-staging PPA. Will this fix make it into Saucy (and so make tablet mode of convertibles usable)?

[Anderson Lizardo (lizardo)]

I got this bug on my laptop running 13.04 (BTW I think bug #946417 is a duplicate of this one). It causes the touchscreen to not work after several clicks.

I tried running the X from x-staging PPA (add-apt-repository ...; apt-get update; apt-get dist-upgrade; service lightdm restart). After I login, the screen shows a background for some seconds and then a blank screen. ~/.xsession-errors shows these lines:

[several lines about loading/starting plugins...]
compiz (core) - Info: Loading plugin: unityshell
gnome-session[2238]: WARNING: Child process 2352 was already dead.
gnome-session[2238]: WARNING: Application 'compiz.desktop' killed by signal 11
gnome-session[2238]: WARNING: App 'compiz.desktop' respawning too quickly
gnome-session[2238]: CRITICAL: We failed, but the fail whale is dead. Sorry....

Do I need to use any other PPA to avoid the compiz crash?

[Anderson Lizardo (lizardo)]

Hi again,

After some investigation, I found that the compiz segfault was due to an undefined symbol:

compiz (core) - Debug: dlopen failed: /usr/lib/compiz/libunityshell.so: undefined symbol: XFixesSelectBarrierInput

I downgraded libxfixes3 to 1:5.0-4ubuntu5.13.04.1 and was able to start Unity properly... But now I found out that the x-org-server package on the x-staging PPA was not updated for raring, only saucy :(

Will try to compile myself, but if you could backport it to raring, I would appreciate.

[Anderson Lizardo (lizardo)]

I gave up and simply upgraded to saucy. So far, I did not have any touchscreen issues, so I've not tried the x-staging PPA for saucy yet.

[Timo Aaltonen (tjaalton)]

the nexus7 either works or not, there might still be a chance of hitting another race but closing anyway

[xcalin (xcalin16-gmail)]

This also affects me on Asus S400CA with Ubuntu 13.04

[inashdeen (inashdeen)]

will the .deb package provided https://launchpad.net/~patola be used on a 64 bit desktop system?

[Maarten Lankhorst (mlankhorst)]

This is reportedly fixed in saucy, I've set up a preliminary backport of the saucy xserver in ppa:ubuntu-x-swat/s-lts-backport can you verify that using this xserver fixes the bug?

[Ara Pulido (ara)]

We have confirmed that the current s-lts-backport fixes the issues as we have seen them.

So, marking as Fix Released for Saucy and we will wait for 12.04.4 for a fix in Precise.

Thanks!

[LJ (the-mr-lj-88)]

Will there be a fix for 13.04 64-bit as well?

[Timo Aaltonen (tjaalton)]

LJ: no, too big set of patches to backport

[LJ (the-mr-lj-88)]

ok, so upgrading to 13.10 is the only option?

[Ara Pulido (ara)]

Tracked on Precise for 12.04.4

[Ara Pulido (ara)]

12.04.4 is now released. Marking as Fix Released in the OEM priority project

[vasya (vasiliy-boytsov-d)]

In ubuntu 14.04 everything seems to be normal.
But when i tried kubuntu 14.04 there was a big similar to this. I can tap the screen but there is no click event. Also some of the windows are "running away" if you're clicking on them. (similar button-stuck behaviour on suse (especially when I tried toucegg (in terminal there was one key repeated constantly))).
My device is acer W700.

[mackie vr (mackie-vr)]

Hi all,
Would really love to get my N7 running ubuntu normally.
I just tried a dist upgrade and the issue still remains in Raring.

Please can someone provide more instructions on getting this fix into the N7 ?

[Timo Aaltonen (tjaalton)]

raring is EOL, and later versions don't have a working tegra3 X driver anymore, so you're out of luck

[Luca Z (luca-zerb)]

I'm on 13.04 on a Nexus7 too and I really would love to find a way to apply these patches, even manually.
Is someone willing to point me to the right direction?
Thank you in advance!