[PATCH xf86-input-evdev] Allow multitouch support to be disabled

[Peter Hutterer]

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