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

[Thierry Reding]

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.

> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121019/6058f50b/attachment.pgp>