On Fri, Oct 19, 2012 at 07:50:04AM +0200, Thierry Reding wrote: > On Fri, Oct 19, 2012 at 08:44:00AM +1000, Peter Hutterer wrote: > > On Thu, Oct 18, 2012 at 12:54:35PM +0200, Thierry Reding wrote: > > > On Thu, Oct 18, 2012 at 08:36:30PM +1000, Peter Hutterer wrote: > > > > On 18/10/12 20:32 , Thierry Reding wrote: > > > > >Instead of always automatically including multitouch support if the > > > > >mtdev library is installed, the new --disable-multitouch option can > > > > >be used to forcefully disable multitouch support in the driver. > > > > > > > > uhm. seems a bit like the proverbial sledgehammer. what's the reason > > > > for this? > > > > > > It turns out that the stuck key issue that I've seen with the OSK is > > > related to multitouch. If I apply this patch to the xf86-input-evdev > > > driver and rebuild with --disable-multitouch the issue is gone. > > > > well, yes. but the real question in this case is whether the bug is in the > > driver (don't think so, given the previous logs), in the server, or in the > > client. > > Early log output seems to indicate that indeed the button press events > are generated by the server but for some reason no release event is > emitted afterwards. > > I've trimmed down the test case to a very rudimentary Gtk+ client that > captures only the button-press and button-release events of a top-level > window and can reproduce with that as well. That has the further > advantage that output from xscope is much reduced since no redrawing > takes place and the only data exchanged is the input events (and the > usual housekeeping). > > Unfortunately some other more urgent stuff came up so I had to postpone > further analysis. I hope I can get more time later today or hopefully > next week to get you a full xscope log along with the test program.
have you looked at Thomas Jaeger's test app? can you reproduce with that one? it's likely the same bug and it's a simpler start than Gtk :) Cheers, Peter > > > I know this is really not a bugfix and we have an upcoming project where > > > we need multitouch support so I'll have to continue looking into the > > > original issue anyway, but this is an acceptable workaround for the > > > present deadline. > > > > > > Besides that I think it's nice to have these knobs to explicitly tell > > > the package to enable support for some feature or not, independent of > > > what the build environment has installed. It helps with reproducibility > > > of a given software configuration. > > > > I understand your point, but I do wonder how many distributions ship evdev > > without mtdev support. I consider multitouch a rather important feature > > these days, one reason I don't want it to be disabled (except on older > > servers) is to make sure we get as much exposure to the code as possible and > > fix the bugs that are there. > > > > tbh, a more useful option regarding multitouch is to skip mtdev for devices > > that don't need it - it would save us some memory that mtdev largely wastes > > on protocol B devices. > > > > but either way, I do want multitouch turned on at all times if possible > > Fair enough. I'll just keep the patch locally until all the multitouch > issues (or at least the one at hand) gets fixed. > > Thierry _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
