Launchpad has imported 43 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=56578.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-10-30T10:01:15+00:00 Timo Aaltonen wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/33 ------------------------------------------------------------------------ On 2012-10-31T16:11:15+00:00 Timo Aaltonen wrote: tried patches from 56558 and 55738, also "Sync TouchListener memory.." from Carlos Garnacho, didn't help. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/34 ------------------------------------------------------------------------ On 2012-11-14T12:03:34+00:00 Daniel d'Andrada wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/35 ------------------------------------------------------------------------ On 2012-11-14T12:04:35+00:00 Daniel d'Andrada wrote: Created attachment 70064 log output of the "repeated tapping on ubuntu logo launcher icon" use case Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/36 ------------------------------------------------------------------------ On 2012-11-19T06:05:14+00:00 Peter Hutterer wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/37 ------------------------------------------------------------------------ On 2012-11-22T11:28:57+00:00 Daniel d'Andrada wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/38 ------------------------------------------------------------------------ On 2012-11-22T12:04:17+00:00 Daniel d'Andrada wrote: 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() Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/39 ------------------------------------------------------------------------ On 2012-11-27T01:11:21+00:00 Peter Hutterer wrote: 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/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/40 ------------------------------------------------------------------------ On 2012-11-27T12:32:11+00:00 Daniel d'Andrada wrote: 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. """ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/41 ------------------------------------------------------------------------ On 2013-01-31T16:36:15+00:00 Jrand wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/43 ------------------------------------------------------------------------ On 2013-02-11T11:49:15+00:00 Timo Aaltonen wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/44 ------------------------------------------------------------------------ On 2013-02-13T23:51:48+00:00 Peter Hutterer wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/45 ------------------------------------------------------------------------ On 2013-02-14T13:17:22+00:00 Timo Aaltonen wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/46 ------------------------------------------------------------------------ On 2013-02-14T22:08:49+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/47 ------------------------------------------------------------------------ On 2013-02-14T22:09:20+00:00 Peter Hutterer wrote: Sorry, to clarify: you need that 1.13 branch linked above AND the patches from Comment 11 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/48 ------------------------------------------------------------------------ On 2013-02-14T22:24:09+00:00 Timo Aaltonen wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/49 ------------------------------------------------------------------------ On 2013-02-25T05:11:00+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/50 ------------------------------------------------------------------------ On 2013-03-01T06:51:44+00:00 Peter Hutterer wrote: Branch available for testing here. I think this fixes the issue but I've been unsuccessful getting this backported to a 1.13 ubuntu server. http://cgit.freedesktop.org/~whot/xserver/log/?h=touch-grab-race- condition-56578-v2 If you can test this, that'd be much appreciated. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/51 ------------------------------------------------------------------------ On 2013-03-04T20:35:25+00:00 Jrand wrote: Hi Peter, I think your recent patches do fix the issue. I compiled your server and a fresh xinput evdev 2.7.3. I confirmed TouchBegin TouchEnd were being sent with a brief xinput test-xi2 test. # xdpyinfo |grep -E '(vendor|version)' version number: 11.0 vendor string: The X.Org Foundation vendor release number: 11399902 X.Org version: 1.13.99.902 My usual scenario to experience this problem is: run Chrome xwininfo [tap root screen, get window id of chrome window] xev -id 0x.... [use window id of chrome window] tap screen a few times to see xev notify events ctrl-C on screen, touch a UI button the press activates the UI button screen switches to new page <-- ButtonRelease is dropped somewhere from here the new UI button underlying where my finger just pressed is stuck down ^--- to here With these same testing steps above I cannot get a stuck button on your new xserver branch. It seems that the ButtonRelease event arrives correctly. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/52 ------------------------------------------------------------------------ On 2013-03-05T06:30:12+00:00 Peter Hutterer wrote: Thanks John, much appreciated. First patchset, minor changes for preparation: http://patchwork.freedesktop.org/patch/13193/ http://patchwork.freedesktop.org/patch/13194/ http://patchwork.freedesktop.org/patch/13195/ http://patchwork.freedesktop.org/patch/13196/ http://patchwork.freedesktop.org/patch/13197/ http://patchwork.freedesktop.org/patch/13198/ http://patchwork.freedesktop.org/patch/13199/ Second patchset, the actual meat: http://patchwork.freedesktop.org/patch/13204/ http://patchwork.freedesktop.org/patch/13205/ http://patchwork.freedesktop.org/patch/13206/ http://patchwork.freedesktop.org/patch/13207/ http://patchwork.freedesktop.org/patch/13208/ http://patchwork.freedesktop.org/patch/13209/ http://patchwork.freedesktop.org/patch/13210/ http://patchwork.freedesktop.org/patch/13211/ http://patchwork.freedesktop.org/patch/13212/ http://patchwork.freedesktop.org/patch/13213/ http://patchwork.freedesktop.org/patch/13214/ http://patchwork.freedesktop.org/patch/13215/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/53 ------------------------------------------------------------------------ On 2013-03-05T15:12:49+00:00 Timo Aaltonen wrote: Ok I've tested them as well by building 1.14rc minus the video abi changing stuff (and commits on top of them), and added the touch branch. This allowed me to test on the nexus7 & tegra3 blob. Looks like it's much better now, although sometimes the touch appears to get somewhat hung but can recover from it later on, and when this happens also generates messages like [ 5101.196] [Xi] Too many valuators reported for device 'Virtual core pointer'. Ignoring event. on the logfile. The buffered actions prior to the hang are replayed after waiting for a while. At this stage it's quite easy to crash the server. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/54 ------------------------------------------------------------------------ On 2013-03-05T22:11:49+00:00 Peter Hutterer wrote: do you have a good backtrace for the crashes? random, or always the same spot? Is it regular in response to some interaction? can it be caused by the backports? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/56 ------------------------------------------------------------------------ On 2013-03-06T09:11:09+00:00 Timo Aaltonen wrote: Created attachment 76003 backtrace Here's the backtrace, seems to be the same every time. Way to reproduce here: 1. open an app, so there's a window around 2. attach an external pointer device 3. tailf the X logfile 4. hit the panel indicators frantically with the touchscreen, until the touch input is locked 5. move the window with the other pointer device 6. see how some "[Xi] ..." messages appear on the logfile 7. repeat the steps until.. 8. .. when the touch input is locked the logfile will get these Xi messages after every touch.. when this happens keep hitting the screen until it crashes, can take a couple of minutes :) so, it's only after using the other pointer device for a grab when the touch input grab is released. Also, while in step 8 I noticed that the multitouch gestures of unity seemed to work, while the panel menus failed to react. Also, Onboard seemed to work as well. So, while locked I can drag a window with a three-touch gesture but not by a single touch drag from the titlebar. Not sure what backports you mean, this is 1.14 with your branch, but ajax's video abi commits reverted so the blob (and thus unity) work. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/57 ------------------------------------------------------------------------ On 2013-03-06T17:50:42+00:00 Maarten Lankhorst wrote: Created attachment 76034 valgrind spam that occurs when following tjaalton's instructions I can reproduce this on x1.14 with my macbook pro in the manner tjaalton described. It didn't need the video abi revert. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/58 ------------------------------------------------------------------------ On 2013-03-07T06:09:31+00:00 Peter Hutterer wrote: did you rebuild the drivers too? just wondering, because I used to get a similar crash on my backports but only when running against the system drivers, not against the upstream ones. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/59 ------------------------------------------------------------------------ On 2013-03-08T05:40:41+00:00 Maarten Lankhorst wrote: I still crashed even if I rebuilt the drivers against the patched xorg- server, so it's not that. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/60 ------------------------------------------------------------------------ On 2013-03-08T06:41:43+00:00 Maarten Lankhorst wrote: It seems that the ubuntu patches for synaptics trigger it, most likely not these: 02-do-not-use-synaptics-for-keyboards.patch - makes synaptics no longer match input.keyboard 101_resolution_detect_option.patch - Add resolutiondetect atom and config option, to add a way to disable autodetect 115_evdev_only.patch - uncomment 50-synaptics.conf 118_quell_error_msg.patch - only affects tools 124_syndaemon_events.patch - only affects syndaemon But these change some things around: 103_enable_cornertapping.patch - sets RTCornerButton default to 2, and RBCornerButton default to 3 104_always_enable_tapping.patch - always sets up tap buttons in set_default_parameters 106_always_enable_vert_edge_scroll.patch - guess :-) 128_disable_three_click_action.patch 129_disable_three_touch_tap.patch - both disable 3 touch actions, to make three-touch gestures work Presumably one of those default tweaks would cause it. I'll try to nail it down. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/61 ------------------------------------------------------------------------ On 2013-03-08T07:08:09+00:00 Timo Aaltonen wrote: well I'm not using synaptics, so it's not the same crasher then? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/62 ------------------------------------------------------------------------ On 2013-03-08T08:03:38+00:00 Maarten Lankhorst wrote: crashes unpatched too, after all :) I guess I didn't hammer enough on the touchpad like a 3 year old Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/63 ------------------------------------------------------------------------ On 2013-03-08T12:56:16+00:00 Maarten Lankhorst wrote: The crash is in xorg-server by the way, not in the driver, and seems to involve memory freed in xorg-server. It just seems more likely that it involves multitouch handling in xorg-server in general, and is not a bug in a specific driver. Either that or there are 2 different bugs in evdev and synaptics that both cause a similar backtrace in xorg-server, this somehow seems less likely to me. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/64 ------------------------------------------------------------------------ On 2013-03-08T23:30:47+00:00 Peter Hutterer wrote: can you bisect the server then? I honestly don't know where it triggers and given that it's 19 patches it'll be easier to bisect than figure it out otherwise. fwiw, I've pushed the rebased branch (only a few squashes and reshuffling), please make sure you pull first. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/65 ------------------------------------------------------------------------ On 2013-03-10T21:14:13+00:00 Maarten Lankhorst wrote: for reference, 1.13 server branch (at time of writing 1.13.3 release) crashes just as hard. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/66 ------------------------------------------------------------------------ On 2013-03-20T16:41:30+00:00 Dsd-o wrote: Thanks a lot for the hard work here. We see the same issue in Sugar, the UI is basically unusable with touch as we have a "global" grab. I tested the patches from comment 19 against xserver-1.14.0, they do solve the problem, and I cannot see any new issues introduced by them. I also tested to 1.13.3. In order to do that I first had to backport a few commits: * Update the MD's position when a touch event is received * Don't use GetTouchEvents when replaying events * Don't use GetTouchEvents in EmitTouchEnd Then I added the patches from comment #19, and things are now working equally well there. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/68 ------------------------------------------------------------------------ On 2013-03-27T10:37:52+00:00 Timo Aaltonen wrote: Created attachment 77097 backtrace the backport seems incomplete, since it's trivial to crash the server with unity by switching between opening the dash or indicator menus Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/69 ------------------------------------------------------------------------ On 2013-04-02T14:50:44+00:00 Dsd-o wrote: The backported patches on 1.13.3 (from comment #32) have now been in OLPC's development builds for over a week and we haven't seen any adverse effects. I've also done some testing on 1.14.0. I can make this crash (with no backtrace) simply by going a bit crazy on the touchscreen for a few minutes, both before and after this patch series. A problem for another day. Based on this I would vote for going ahead with the merge of this patch series into master. I also found a related bug with both 1.13.3 and 1.14.0 (both before and after these patches), and posted a patch here: http://lists.x.org/archives/xorg-devel/2013-April/035878.html Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/70 ------------------------------------------------------------------------ On 2013-04-08T17:41:40+00:00 Maarten Lankhorst wrote: first valgrind error is on int emulate_pointer = ! !(ev->device_event.flags & TOUCH_POINTER_EMULATED); So I guess it's safe to assume that ev is garbage.. Other writes seem to be related to ev too, judging from the valgrind output I guess random stuff gets overwritten. Looking at SetTapState output: 0 -> 1 1 -> 10 moving state stuff 10 -> 2 2 -> 10 moving state stuff 10 -> 2 and then a few more 2 -> 10 and 10 -> 2 with moves until valgrinds starts complaining and xserver starts crashing: (II) SetTapState - 10 -> 2 (millis:3928387395) ==25788== Invalid read of size 4 ==25788== at 0x24236E: ProcessOtherEvent (exevents.c:1519) ==25788== by 0x264CAE: ProcessPointerEvent (xkbAccessX.c:751) ==25788== by 0x166641: PlayReleasedEvents (events.c:1217) ==25788== by 0x16DED4: ComputeFreezes (events.c:1297) ==25788== by 0x16E2E3: AllowSome (events.c:1725) ==25788== by 0x16E495: ProcAllowEvents (events.c:1785) ==25788== by 0x15DC45: Dispatch (dispatch.c:432) ==25788== by 0x14C5B9: main (main.c:295) ==25788== Address 0x122336b0 is 16 bytes before a block of size 152 free'd ==25788== at 0x4C2BA6C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25788== by 0x806D84A: sna_mode_wakeup (sna_display.c:3500) ==25788== by 0x161F3B: WakeupHandler (dixutils.c:426) ==25788== by 0x2AF6E3: WaitForSomething (WaitFor.c:224) ==25788== by 0x15D9A0: Dispatch (dispatch.c:361) ==25788== by 0x14C5B9: main (main.c:295) This is with the patches from comment #19 + daniel drake's patch Digging more, looking up the InternalEvent struct.. int emulate_pointer = ! !(ev->device_event.flags & TOUCH_POINTER_EMULATED); Now this is a function that is looking verrrrrrrry suspicious for type == ET_TouchOwnership.. I think it would make sense to have ET_TouchOwnership handled directly by ProcessTouchOwnershipEvent, rather than through ProcessTouchEvent. Patch attached below.. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/71 ------------------------------------------------------------------------ On 2013-04-08T17:42:21+00:00 Maarten Lankhorst wrote: Created attachment 77621 Call ProcessTouchOwnershipEvent directly Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/72 ------------------------------------------------------------------------ On 2013-04-11T09:54:42+00:00 Maarten Lankhorst wrote: Valgrind came up with this complaint on 1.13.3 with the backported patches: ==15921== Invalid read of size 4 ==15921== at 0x1D0A00: DeliverTouchEvents (exevents.c:1297) ==15921== by 0x1D2589: ProcessOtherEvent (exevents.c:1611) ==15921== by 0x1567C1: TouchEventHistoryReplay (touch.c:491) ==15921== by 0x1D0EBB: TouchPuntToNextOwner (exevents.c:1120) ==15921== by 0x1D11EB: TouchRejected (exevents.c:1196) ==15921== by 0x1D28B5: ProcessOtherEvent (exevents.c:1223) ==15921== by 0x1E7DAB: ProcessPointerEvent (xkbAccessX.c:751) ==15921== by 0x204DC5: mieqProcessDeviceEvent (mieq.c:556) ==15921== by 0x1570A7: TouchListenerAcceptReject (touch.c:1013) ==15921== by 0x1D6AD3: ProcXIAllowEvents (xiallowev.c:128) ==15921== by 0x1D2BD5: ProcIDispatch (extinit.c:406) ==15921== by 0x13CC0D: Dispatch (dispatch.c:428) ==15921== Address 0xc6a0bac is 4 bytes inside a block of size 68 free'd ==15921== at 0x482E5B0: free (vg_replace_malloc.c:446) ==15921== by 0x14C129: DeletePassiveGrab (grabs.c:336) ==15921== by 0x1527FD: doFreeResource (resource.c:873) ==15921== by 0x152F7F: FreeResource (resource.c:903) ==15921== by 0x14C49F: DeletePassiveGrabFromList (grabs.c:686) ==15921== by 0x144A7D: ProcUngrabButton (events.c:5640) ==15921== by 0x13CC0D: Dispatch (dispatch.c:428) ==15921== by 0x132035: main (main.c:298) I picked the fixes from 57301 to 1.13 too: Xi: fix touch event selction conflicts (#57301), and the commit before that to make it apply. This brings 1.13 dix and Xi to the 1.14 equivalent minus pointer barriers, as far as I can tell, but then I was getting the following segfault: ==1748== Invalid read of size 4 ==1748== at 0x4831DCC: memcpy (mc_replace_strmem.c:878) ==1748== by 0x156959: TouchConvertToPointerEvent (touch.c:637) ==1748== by 0x1D0FA3: DeliverTouchEmulatedEvent.isra.0.part.1 (exevents.c:1375) ==1748== by 0x1D0C5F: DeliverTouchEvents (exevents.c:1920) ==1748== by 0x1D25B1: ProcessOtherEvent (exevents.c:1611) ==1748== by 0x1E7E03: ProcessPointerEvent (xkbAccessX.c:751) ==1748== by 0x1423B1: PlayReleasedEvents (events.c:1214) ==1748== by 0x146D13: ComputeFreezes (events.c:1294) ==1748== by 0x146F6B: AllowSome (events.c:1722) ==1748== by 0x1470BF: ProcAllowEvents (events.c:1785) ==1748== by 0x13CC0D: Dispatch (dispatch.c:428) ==1748== by 0x132035: main (main.c:298) ==1748== Address 0xcaa1284 is 156 bytes inside a block of size 280,000 free'd ==1748== at 0x482E5B0: free (vg_replace_malloc.c:446) ==1748== by 0x1570E3: TouchListenerAcceptReject (touch.c:1015) ==1748== by 0x146D6F: ComputeFreezes (events.c:1282) ==1748== by 0x146F6B: AllowSome (events.c:1722) ==1748== by 0x1470BF: ProcAllowEvents (events.c:1785) ==1748== by 0x13CC0D: Dispatch (dispatch.c:428) ==1748== by 0x132035: main (main.c:298) Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/73 ------------------------------------------------------------------------ On 2013-04-11T11:15:39+00:00 Maarten Lankhorst wrote: Note: macbook pro (synaptics) seems to work just fine with the 1.13.3 backports, so it looks like it's a separate bug due to different behavior on a true touch device. The valgrind backtraces were on arm/tegra, which also enables a software keyboard. The easiest way to crash on ubuntu's xserver on the tegra is by making sure valgrind is running with --free-fill=fe so the freed memory is always reset to an invalid value. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/74 ------------------------------------------------------------------------ On 2013-04-17T06:54:23+00:00 Till Kamppeter wrote: Created attachment 78124 touch-fix.patch I have partial (full?) success (on the Lenovo Thinkpad Twist, an Intel- based convertible, see also https://launchpad.net/bugs/1068994 and https://launchpad.net/bugs/1015183): I have rebuilt the current Ubuntu Raring package of xorg-server (1.13.3-0ubuntu5) with the following two patches: 1. http://cgit.freedesktop.org/~whot/xserver/commit/?h=touch-grab-race- condition-56578-v2&id=0498a4f0e0b90a850df7022a3356f10adabff855 (found via comment #17) 2. http://lists.x.org/archives/xorg-devel/2013-April/035878.html and after that clicking via touch screen on the Lenovo Thinkpad Twist works reliably. Only remaining (minor) problems are (but the touch click ability does not get lost by them): a. In Chromium when you create a new tab, the new tab contains icons for web apps (at least the app store and perhaps some examples). These icons cannot be clicked by touch, only with a mouse. All the rest in Chromium is clickable by touch. b. Touch clicks do not work in XBMC, but after using and leaving XBMC with an external mouse on the normal desktop touch-clicking works again. These are probably separate bugs which got revealed by the now working touch click. Complete patch for xorg-server is attached. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/79 ------------------------------------------------------------------------ On 2013-04-17T08:07:25+00:00 Till Kamppeter wrote: Created attachment 78125 touch-fix.patch Sorry, patch is not complete. Here is the correct one. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/81 ------------------------------------------------------------------------ On 2013-04-17T08:13:08+00:00 Peter Hutterer wrote: ok, thanks to Maarten's debugging we've found the issue. listener->grab is not copied but rather referenced, leaving the grab stale once it was deleted. Reproducible test case is simply: XGrabButton() pointer-emulating touch down XUngrabButton() trigger touch update/end This doesn't necessarily crash, but once you run through valgrind to reset memory after freeing it we have a reliable crasher. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/82 ------------------------------------------------------------------------ On 2013-04-17T09:17:42+00:00 Till Kamppeter wrote: I have built xorg-server with my patch also on the Nexus 7 (armhf) now and it works perfectly there with the desktop and all applications, too, and on the Nexus 7 XBMC and Chromium's web apps work with touch. It also seems to fix the Nexus 7. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1015183/comments/84 ** Changed in: xorg-server Status: Unknown => In Progress ** Changed in: xorg-server Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1015183 Title: Inconsistent mouse events for Acer T231H multitouch monitor To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1015183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
